Arquitectura de software, rol e integracion de aplicaciones

En el presente post, comparto un documento académico que hice con respecto al tema de referencia.

http://bit.ly/bfSKOR

El resumen de este documento fue posteado en

My Software Architecture Presentation

Habilidades de un arquitecto de software

 

La visión general de  un arquitecto de software es un experto en tecnologías de desarrollo, sería el encargado de proveer soluciones tecnológicas óptimas para los problemas del negocio. Además se espera que esas soluciones se integren correctamente con los componentes y soluciones existentes y planeadas.

El arquitecto se tiene que comportar como un arqueólogo, con inventiva, innovación, capacidad de mediación, negociación y liderazgo.

Por lo tanto se pretende que sea especialista pero a su ver tenga una visión general de todas las etapas del ciclo de vida del desarrollo del software. Esto le permite al arquitecto controlar aspectos de calidad en el desarrollo desde el inicio hasta la implementación en ambiente productivo y su posterior mantenimiento

Dado que es prácticamente imposible ser especialista en todas las áreas del ciclo de vida del desarrollo del software y a su vez tener una visión general del proceso existen las clasificaciones de los diferentes tipos de arquitectos de IT.

 

Joseph Hofstader agrega una visión del arquitecto desde el punto de vista de las habilidades de diseño. En la etapa inicial del proyecto debe tener una visión conceptual del mismo en base a los requisitos funcionales y las restricciones del negocio, en una etapa posterior se debe diseñar desde el punto de vista del modelo de dominio, puede ser horizontal o vertical, horizontal es aplicable a través de diferentes industrias y la vista de dominio vertical es aplicable a un industria en particular, se suele subestimar las habilidades para modelar dominios verticales, pero no es lo mismo el modelo de dominio para una empresa de banca, de telecomunicaciones, servicios o metalúrgica,  está habilidad tiene que ser estimada por los CIOs y aprovechada para brindar valor agregado a los diseños de los sistemas de la compañía.

Estos dos aspectos definen la definición del problema, tal como se muestra en la figura existe una segunda etapa que se basa a el desarrollo de la solución

 

 

 

 

Conocer cómo trabaja una tecnología no es lo único que se debe saber para diseñar aplicaciones robustas, dedicarle esfuerzo a esta etapa no es menos importante que las anteriores, pues un profundo conocimiento de la tecnología a aplicar permite al arquitecto alinear las especificaciones funcionales al diseño técnico. Es recomendable trabajar con el mínimo de tecnologías posibles, esto permite administrar el esfuerzo del desarrollo en forma más eficiente, reduciendo la cantidad de herramientas de administración, desarrollo, monitoreo etc, teniendo grupos con menos perfiles técnicos etc. [Hofstader Joseph, 2008].

 

 

 

Existe otra clasificación de los roles difundida por el IASA [Akenine Daniel, 2008] que está relacionada con ciertas actividades que debe realizar un arquitecto clasificada en 3 niveles y 40 artefactos a generar.

 

• Nivel 1: Los arquitectos y los responsables del negocio crean estrategias juntos  de cómo alinear las estrategias del IT con las del negocio. Estos principios y políticas tienen influencia en toda la organización. Ejemplos de entregables en este nivel son planes de desarrollo de software , visiones y estrategias
• Nivel 2: Los arquitectos crean artefactos que soportan la relación entre el negocio y la tecnología. A este nivel, los arquitectos intentan entender el proceso de la organización y como pueden mejorarlo usando las capacidades que provee el área de IT. Ejemplos de este tipo de artefactos son diagrama de procesos y de servicios.
• Nivel 3: Producen artefactos para el modelado técnico de la arquitectura, utilizan las mejores practicas de diseño posibles para crear buenas soluciones, tales como equilibrio entre costo y funcionalidad, escalabilidad, flexibilidad, seguridad y otros atributos de calidad. Dentro de este nivel están los modelos de aplicación, de datos, de dominio, de componentes, capas, objetos etc.

 

 

Habilidades blandas

 

Un arquitecto tiene que tener la habilidad de manejar relaciones inter personales entre los miembros de su equipo, los líderes de los proyectos, los clientes y usuarios manejando una adecuada comunicación y lenguaje acorde con cada perfil de interlocutor.  Es un error común hablar con lenguaje excesivamente técnico con un analista funcional o líder de usuario cuando en realidad se debería expresar en términos de procesos de negocio e interfaces de usuario y que valor agregado otorga el sistema al negocio.

Debe tener la habilidad de bajar a un nivel de atracción adecuado las especificaciones recibidas desde los usuarios que solicitan determinado sistema, para ello se requiere la habilidad de relevar la información necesario de esas personas.

 

Habilidades técnicas

 

La visión general que tiene el arquitecto le permite diseñar el sistema con un cierto nivel de abstracción que le permita describir todo el sistema.

En sistemas muy grandes estos diseños iniciales se subdividen en sistemas más pequeños que para poder simplificar el diseño. Estos subsistemas pueden estar construidos en diferentes tecnologías, implementados en infraestructuras diferentes, pudiendo ser construidos dentro de la empresa, por un tercero o bien ser un producto comercial. El diseño debe permitir integrar todos los sub sistemas mediante la utilización de estándares de integración de aplicación aplicables en la empresa.

Para un correcto diseño se debe tener bien identificados los requisitos funcionales, tener un adecuado conocimiento de las tecnologías, productos y sistemas implementados en la compañía, conocer sus ventajas y desventajas y luego decidir si utilizar productos y sistemas ya existentes, adaptarlos a las necesidades, construir nuevos o impulsar la adquisición de productos comerciales que se adapten a todo o parte de la necesidad del negocio. En el capitulo referentes a Diseño de Arquitecturas se analizará con más detalle este tema.

 

Referencias

 

1. [Akenine Daniel, 2008], “A Study of Architect Roles by IASA Sweden”, Architecture Journal 15, MSDN Architecture Center,  http://msdn.microsoft.com/en-us/architecture/cc505968.aspx 
2. [Hofstader Joseph, 2008], “We Don't Need No Architects”, Architecture Journal 15, http://msdn.microsoft.com/en-us/architecture/cc505974.aspx