El Arquitecto ocupa un rol crítico dentro del proyecto

El Arquitecto ocupa un rol crítico dentro del proyecto, que impactará directamente en el éxito del proyecto. El arquitecto reutiliza experiencia de proyectos exitosos pasados, analizando patrones y analogías a distintos niveles de abstracción. El Arquitecto es además un facilitador, no debe tomar decisiones de forma unilateral o irracional (es pragmático), evitando los riesgos del proyecto. Es responsable de todos los aspectos técnicos de una solución, los cuales se pueden definir al más alto nivel como la "Arquitectura del Sistema". Esta "Arquitectura" se diseña de manera de poder resolver satisfactoriamente todos los requerimientos (funcionales y no funcionales) del proyecto. Desde el punto de vista funcional (o "de negocio") el arquitecto debe ser capaz de tener un diálogo fluido con los interlocutores "del negocio" (los clientes o usuarios del sistema) a fin de entender claramente su problemática y poder diseñar la arquitectura correcta que cumpla con estos objetivos. Desde el punto de vista "no-funcional" el arquitecto debe poder relevar, entender, definir y documentar todos los requerimientos no funcionales del sistema, para así estar en condiciones de diseñar la arquitectura adecuada que cumpla con estos requisitos adicionales. Debe tener excelentes cualidades de comunicación para poder relevar apropiadamente todos estos aspectos del sistema y poder diseñar el mejor sistema posible. Es de especial importancia recordar que la comunicación escrita que debe generar un arquitecto debe ser de muy buena calidad y nivel de detalle suficiente como para que no haya dudas sobre las decisiones de arquitectura y diseño tomadas. Es por este constante canal de comunicación abierto hacia las áreas de negocio como para las áreas tecnológicas encargadas de la ejecución del proyecto, que se dice que es el arquitecto quien actúa de nexo entre estas dos áreas y tiene la capacidad de entender, pensar y actuar como cualquiera de ellos. Este canal permanente de comunicación hace que el arquitecto sea el nexo natural entre estas áreas y tenga que resolver la diferencia de impedancia que existe entre los intereses de las mismas. Por ejemplo, el arquitecto tiene que poder resolver conflictos entre diferentes expectativas, fechas de entrega, funcionalidad, recursos necesarios versus disponibles y muchas otras fuentes de potenciales conflictos, siempre entendiendo y primando las necesidades de negocio que se intentan resolver con este proyecto en particular. Existe además, la noción de que el arquitecto tiene cierto nivel de conocimiento y experiencia en todos los campos arriba mencionados así como en diversos dominios de negocio, con un claro componente de pasión por la tecnología en general pero además con un marcado interés en la mejora continua y la difusión/enseñanza (o preservación) de lo que constituye los aspectos ingenieriles de una buena "artesanía" (craftmanship). Responsabilidades del Arquitecto a. Orientación al Objetivo: Satisfacción del Cliente #1 b. Tener habilidades de comunicación y negociación c. Conocer, crear y defender decisiones de tipo económicas d. Identificar, crear y visionar nuevas oportunidades e. Alinearse con la estrategia y política corporativa f. Satisfacer necesidades corporativas g. Conocer dominios de negocio 1. Para con Lagash, debe enfocarse en: a. Tener una buena capacidad de comunicación b. Tener capacidad de escuchar y observar c. Tener capacidad de liderazgo, comunicando apropiadamente para persuadir, motivar y guiar. d. Ganarse el respeto de sus pares, líderes, usuarios y la comunidad en general e. Coordinar equipos de trabajo f. Colaborar con los líderes de desarrollo y de otras áreas estrechamente g. Promover y administrar ambientes de discusión sobre temas relevantes h. Resolver conflictos i. Ser un líder técnico (toma de decisiones) j. Apoyar técnicamente (coaching, soporte) k. Ayudar y apoyar en la selección y formación del equipo 2. Para con las personas, debe: a. Tener la visión global del proyecto b. Definir las directrices o bases de la arquitectura (premisas de diseño) 3. Para con el Proyecto, es responsable de: El Arquitecto jueves, 05 de febrero de 2015 03:57 p.m. Engineering página 1 b. Definir las directrices o bases de la arquitectura (premisas de diseño) c. Diseñar, proponer, defender, negociar y evangelizar la arquitectura d. Entender y planear las rutas de evolución del sistema, diseñar un plan que guíe la adopción de nueva tecnología e. Seleccionar plataforma, herramientas, tecnologías, frameworks y patrones f. Tomar las decisiones clave de arquitectura y diseño, justificando estas decisiones g. Asistir en la selección de los miembros del equipo h. Define estrategias de branching y versionado, soporte a producción y release Identificar riesgos asociados a las decisiones técnicas y arquitectura definidas, presentar estrategias de mitigación y negociarlas con las áreas involucradas (negocio, tecnología, infraestructura, seguridad, desarrollo, etc.) i. j. Define estrategias de administración de referencias Garantiza la integridad arquitectónica del sistema y se encarga de que todos los involucrados la entiendan y entiendan sus objetivos (qué, cómo y porqué) k. Garantizar la calidad de los entregables, implementando y monitoreando prácticas de ingeniería tendientes a mejorar la calidad del código l. m. Asegurarse que se cumpla con la solución propuesta n. Aspectos no funcionales de la arquitectura (performance, escalabilidad, seguridad, monitoreo, etc.) a. Autoridad para tomar decisiones técnicas b. Interés por mantenerse actualizado c. Capacidad de aprendizaje rápido d. Profundos y a la vez amplios conocimientos tecnológicos 4. Para con la Tecnología, debe tener: Tareas del Arquitecto A veces durante el proyecto y a veces en una etapa anterior (anteproyecto) el arquitecto utiliza los datos del proyecto (casos de uso principales, requerimientos no funcionales, atributos de calidad y restricciones) para realizar el diseño de arquitectura i. a. Tareas de Pre-Diseño y prototipos, diagramas, esquemas, decisiones y supuestos b. Adelantarse a tareas futuras haciendo POCs sobre requerimientos que tienen incertidumbre técnica c. Documentar la arquitectura y decisiones de diseño d. Tareas de refactoring para evolucionar la arquitectura Uso de prácticas de calidad de código: Testing Unitario, DI, Mocks, Análisis estático de código, code coverage, complejidad ciclomática, acoplamiento, etc. i. Convenciones de nombres y diseño (Style/Design Guides) en carpetas, soluciones, proyectos, clases, namespaces, clases, métodos, parámetros, etc. ii. iii. Warning as Errors, manejo de excepciones, tests de buena calidad, etc. iv. Integración continua, automatización (builds, tests, deploys, etc.) e. Garantizar el cumplimiento de estándares y buenas prácticas dentro del equipo f. Realizar revisiones de código periódicas y regulares g. Identificar cosas a mejorar en procesos o herramientas y proponer soluciones posibles h. Si no hay un responsable definido, realizar las tareas de Release Management i. Realizar las tareas de branching y merging de cada sprint y/o release j. Colaborar con las tareas de diseño del equipo, evaluar los diseños propuestos k. Colaborar con el PM para priorizar tareas y definir riesgos Participar activamente de las tareas de estimación de requerimientos, velando de que se cumplan las buenas prácticas al respecto (breakdown de tareas, por ejemplo) l. 1. En el Proyecto a. Participar en tareas de Pre-Venta y soporte al área comercial b. Ayudar a RRHH a definir roles y responsabilidades técnicos, planes de capacitación, conocimientos, etc. c. Asistir en tareas de capacitación, coaching y mentoring d. Participar en tareas de investigación en nueva tecnología e. Participar en tareas de selección y/o construcción de frameworks / componentes reutilizables 2. Fuera del Proyecto Que diferencia un Arquitecto de un Desarrollador Senior 1. Carácter Engineering página 2 a. Capacidad de trabajar bajo presión y con grandes incertidumbres b. Líder, buen comunicador y negociador c. Autodidacta, apasionado 1. Carácter a. Tiende a ser un generalista más que un especialista, y puede enfocarse a un punto en particular de ser necesario b. Visión holística del sistema, incorporando aspectos tecnológicos, de negocio, económicos, estratégicos, etc. c. Proyección a futuro de la tecnología y las tendencias de negocio, y su interacción. d. Investigación constante de nuevas tecnologías. 2. Foco a. Análisis de costos y estados financieros, rentabilidad de un proyecto i. Dominios de Negocio ii. Procesos de desarrollo de software iii. Seguridad y confidencialidad de datos y sistemas iv. Plataforma, infraestructura y redes de comunicación v. Mecanismos y procesos para lograr escalabilidad, tolerancia a fallos, recuperación ante desastres vi. Aspectos legales relacionados (compliance, auditoría, normativa vigente, etc.) vii. Comprender estilos de arquitectura, frameworks arquitectónicos y metodologías de diseño b. Diferentes áreas de conocimiento que abarca una solución tecnológica 3. Conocimiento y experiencia Confusiones comunes El término Arquitecto de Software se ha convertido en el título de moda en toda empresa de sistemas o con un área propia de sistemas. Decimos de moda, debido a que no todas las empresas necesitan realmente arquitectos de software y, tal vez, ni siquiera todos los proyectos necesiten de un verdadero arquitecto de software. Es común que muchas de las tareas relevantes de un proyecto puedan ser perfectamente resueltos con desarrolladores experimentados, sin tener la necesidad de utilizar un arquitecto. Muy frecuentemente se tiende a confundir estos dos perfiles, que son muy diferentes. También es importante notar la diferencia entre los “gurúes tecnológicos” y los verdaderos arquitectos. Estas cuestiones aumentan la confusión existente sobre qué es un arquitecto y cuáles se supone tendrían que ser sus responsabilidades. Existen otras figuras a las que habitualmente se les asigna este título de forma arbitraria; y que no siempre lo justifican, como ser: • Ingenieros Engineering página 3 • Ingenieros • Científicos • Web masters • Project managers • Consultores • Analistas con profundo conocimiento del negocio • DBA’s Clasificación de Arquitectos Hay muchas formas posibles de clasificar a los Arquitectos, según su alcance o foco, experiencia, etc. Abajo podemos ver la clasificación que propone Microsoft según dos variables: foco en estrategia y tecnología. Una posible clasificación para Lagash podría ser el mostrado en el diagrama de abajo. Cada empresa define sus roles de acuerdo a sus necesidades y cultura, por lo que este esquema aplica solamente a una empresa como la nuestra. Engineering página 4 Referencias http://ccia.cujae.edu.cu/index.php/siia/siia2010/paper/viewFile/767/47 http://apit.wdfiles.com/local--files/start/06_apit_rol_del_arquitecto.pdf http://www.epidataconsulting.com/tikiwiki/tiki-read_article.php?articleId=7 http://itblogsogeti.com/2014/07/29/cual-es-la-funcion-de-un-arquitecto-de-software-carlos-mendible-sogeti/ http://www.slideshare.net/soreygarcia/el-roldel-arquitecto-exposicion http://www.tec.url.edu.gt/boletin/URL_19_SIS02_COMPETENCIAS.pdf http://www.pmoinformatica.com/2013/10/el-rol-del-arquitecto-de-software.html http://www.pmoinformatica.com/2013/11/rol-arquitecto-software-2da-parte.html https://jorgeportella.files.wordpress.com/2010/12/asi-se-realiza-un-estado-del-arte.pdf http://sg.com.mx/revista/33/el-rol-del-arquitecto-software#.VNPEG52G9UU http://geeks.ms/blogs/oalvarez/archive/2009/07/02/funciones-principales-de-un-arquitecto-de-software.aspx http://www.marioperez.com.mx/blog/roles-y-responsabilidades-en-un-equipo-de-desarrollo-de-software/ Engineering página 5 https://prezi.com/dhuxvlxnvbt8/roles-y-responsabilidades-del-arquitecto-de-software/ Engineering página 6

...