14 arquitectura de sistemas

Arquitectura de Sistemas

M.B.A. Ing. Luis H. Vidal V.

[email protected]

• 5.1.- Identifica las funciones que realiza y las competencias técnicas y organizacionales que debe tener un arquitecto de software.

Aprendizajes Esperados/Desempeños

Introducción.

• De la misma manera que ocurre con la Arquitectura de Software, existen múltiples definiciones sobre el rol de los arquitectos. Podríamos incluso citar una definición por autor.

El rol de los Arquitectos de Software

• La realidad parece indicar que es poco probable que se pueda dar una definición de arquitecto, transversal a cualquier organización.


• Definir un estereotipo de arquitecto que especifique cuáles son sus responsabilidades y habilidades necesarias dentro de un proyecto. Lo que sí es posible es definir prototipos de arquitectos “a muy grandes rasgos” y aplicar cada uno de estos arquetipos, en una situación en particular, dependiendo del contexto de la empresa, del proyecto y del equipo de trabajo.


• 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 contratar un arquitecto.


• Muy frecuentemente se tiende a confundir estos dos perfiles, que son abismalmente 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• Científicos• Web masters• Project managers• Consultores• Analistas con profundo conocimiento del negocio• DBA’s


Tipos de arquitectos de software

• Para definir qué es un arquitecto de software, debemos tener en cuenta un contexto y un escenario en particular. Dicho de otra forma, depende de la organización, de su negocio, de sus objetivos, de la influencia del área de sistemas, de la importancia de el/los proyecto/s y del tamaño de los mismos.


•Teniendo en cuenta este contexto, podemos proponer una serie de categorizaciones:•Arquitecto Técnico.•Arquitecto Funcional.•Arquitecto Corporativo.

Fuente: Carnegie Melon


•Arquitecto técnico• Se trata de profesionales con amplios conocimientos

técnicos, conocedor del negocio de los proyectos y que, probablemente, esté asignado a uno o varios proyectos al mismo tiempo. Algunas de sus responsabilidades suelen ser: definir los lineamientos de diseño, su arquitectura y demás cuestiones técnicas de los proyectos.


• Arquitecto funcional• Tienden a ocupar el rol de team leader y, a su vez, de líder técnico.

Manejan el projecto y planifican junto al PM las iteraciones. Suele representar un canal de comunicación fluida entre el PM y los equipos de desarrollo. Validan diseños; guían a los desarrolladores, para que cumplan con las expectativas de calidad tomando métricas, organizando y promoviendo la documentación y las buenas prácticas; aseguran que el proyecto no se desvíe de la arquitectura previamente definida.


• Arquitecto Corporativo• Unifica los dos casos mencionados anteriormente; pero con

algunos agregados.

• Probablemente, en la literatura referida al tema se logre recopilar una mayor cantidad de perfiles o roles de arquitectos. Esta mayor variedad, en general, apunta a grandes organizaciones, donde cada función está claramente dividida y, sobre todo, limitada, transformando al arquitecto en un ente con responsabilidades restringidas.


Arquitectos. Amplitud vs profundidad.

Enterprise Architect. Arquitectos empresariales repartidas en un LOB (Line of Business ) y de TI ámbitos como la seguridad, la infraestructura, la información o el desarrollo.

Arquitecto de dominio. Arquitectos de dominio centrarse en un dominio específico y tienen amplia experiencia esa zona. Normalmente, estos arquitectos se enfocan en áreas específicas, Ejemplos de estos incluyen: Arquitecto de negocios, arquitecto de seguridad, Arquitecto de Información, Infraestructura Arquitecto, Arquitecto Comunicaciones, etc.

Desarrollador. Los desarrolladores centrarse en una solución a la vez y tienen una amplia experiencia en el desarrollo.

Rol de los arquitectos de Software.

• Como base, el rol de los arquitectos suele comprender las siguientes tareas:• definición de las vistas de la arquitectura de una aplicación (o sea, CREAR la

arquitectura, ya que la arquitectura, en pocas palabras es un conjunto de vistas de alto nivel);

• dar soporte técnico-tecnológico a desarrolladores, clientes y expertos en negocios;

• conceptualizar y experimentar con distintos enfoques arquitectónicos;

• crear documentos de modelos y componentes y especificaciones de interfaces;

• validar la arquitectura contra requerimientos, suposiciones;


• Y además:• tener una dosis de estrategia y política, o sea, ser, en parte, un CONSULTOR.

• De esta forma logramos unificar el arquitecto técnico con el arquitecto funcional, resultando un arquitecto corporativo. Una figura que probablemente se ajuste a cualquier realidad (adaptando algunos puntos específicos de sus tareas).


Dominios de los arquitectos

• En el rol cotidiano de los arquitectos, existen varias tareas o dominios (más allá de las tareas propias incluidas en el ciclo de vida de un proyecto en particular) en los que suelen estar enfocados los arquitectos y que es conveniente determinar.


• tecnología• enfocado más en los objetivos de la organización que en las

decisiones técnicas

• creación de modelos problema/solución

• exploración de alternativas de soluciones

• preparación de documentos

• convencer y comunicar de la factibilidad de las decisiones técnicas a los sponsors y stake holders


http://en.wikipedia.org/wiki/Stakeholder

•estrategias de negocios:• claro conocimiento de la estrategia de negocio de la organización,

de los ciclos de planificación, proceso de toma de decisiones; conocimiento del contexto de la organización (competencia, productos, factores principales que afectan el éxito de la organización),

• todo esto se resume en VENDER, pero no desde el punto de vista comercial, sino mas bien, desde el punto de vista de la actitud, la comunicación y lo valores de calidad trasmitidos.


•políticas de la organización:

• conocer los principales stake holders de la organización. Especialmente, saber lo que ellos quieren y necesitan; mantener una comunicación fluida con éstos.

• generación de reportes y comunicación de resultados.


http://en.wikipedia.org/wiki/Stakeholder

• liderazgo:• tener una visión del contexto

• toma de decisiones

• selección y creación equipos

• motivador

• tener carisma y credibilidad

• compromiso y dedicación

• evangelización tecnológica

• puente entre desarrolladores, PM's y expertos de negocio.


• Sabemos que los arquitectos también forman parte del proceso de desarrollo de un proyecto. Durante este proceso, las fases comúnmente reconocidas como más importantes en la actuación del Arquitecto de Software son:

• pre-diseño:• entender el alcance del proyecto

• entender los puntos más importantes del diseño: validar y manejar requerimientos y expectativas del cliente

• análisis de dominio:• entender en detalle los requerimientos del cliente

• crear bocetos de los comportamientos deseados del sistema


• diseño esquemático:• definir el look&feel

• si es necesario, construir prototipos

• desarrollo de diseño:• ampliar los detalles y refinar el diseño para llegar al diseño final

• finalizar todos los diseños


• documentos del proyecto:• soporte a desarrolladores: lidiar con problemas concretos, revisión de código

para controlar la calidad, ver cómo funcionan (o no) las cosas

• definir el proceso de desarrollo, los roles de los miembros del team y la secuencia de construcción de la aplicación

• especificar metodologías y tecnologías.

• definir todos los detalles necesarios para todos aquellos que construirán la aplicación

• contratación o staffing:• seleccionar desarrolladores

• si el desarrollo es tercerizado, participar en la elección del proveedor


• construcción:• asegurar que la visión del cliente sea mantenida y respetada durante el

desarrollo• revisar y validar los diseños de nivel de construcción si la complejidad de los

mismos lo amerita• diseñar modificaciones pedidos por el cliente.• participar en el testeo y aceptación de la revisiones solicitadas por el cliente

• post construcción:• asistencia en la migración del sistema nuevo (implementación)• puede llegar a manejar el entrenamiento de los usuarios nuevos• definir procesos de mantenimiento


Tarea

• Ejemplo de contrato que permita contratación o staffing:

14 arquitectura de sistemas

Education

Transcript of 14 arquitectura de sistemas