Arquitectura TI: Que es y que hace un arquitecto de TI?

Introducción:
Previamente publiqué un post sobre la Arquitectura MVC pero... qué es realmente la arquitectura de software? cuál es el rol del arquitecto? Hay herramientas que faciliten la labor del arquitecto?

Definición:
La arquitectura de software, llamada también la arquitectura lógica, es el diseño de mas alto nivel de la estructura de un sistema, aunque hay varias definiciones y no hay prácticamente ninguna que sea totalmente aceptada, aunque la más oficial es la definición oficial de Arquitectura del Software es la IEEE Std 1471-2000 que dice: “La Arquitectura del Software es la organización fundamental de un sistema formada por sus componentes, las relaciones entre ellos y el contexto en el que se implantarán, y los principios que orientan su diseño y evolución”.

Otra definición es la de Hohmann, 2003: “Arquitectura de software es la suma de los módulos complejos, procesos y los datos del sistema, su estructura y exactas relaciones entre sí, cómo puede ser y se espera que sea, sus extensiones y qué tecnologías participan, deducir las capacidades exactas y flexibilidad del sistema desde el cual se puede formar un plan para la implementación o modificación del sistema.”

El Rol del arquitecto de software:
El arquitecto es el encargado de definir:
QUE?
La union de requerimientos del cliente, el conocimiento de su entorno, de sus necesidades, de sus espectativas de crecimiento, dan como resultado un producto intangible que será la solución que se va a proveer considerando un modelamiento del negocio conformado por el equipo de analistas que apoyan cada proyecto.
Acá se hace un paralelo con un drector de orquesta, que debe hacer que cada uno de los músicos interpreten la música de acuerdo a la partitura.


COMO?
Una vez que está definido el qué se va a hacer, definidos ya el modelo de negocios, con los analistas que conforman el negocio, se confecciona la documentación técnica del proyecto que contiene análisis, modelos y diseño de la solución a los requerimientos del cliente. El arquitecto cumple su parte como organizador, facilitador de definiciones y como validador del modelamiento.

CON QUE?
Nuevamente el arquitecto entra en su rol de "director de orquesta" esta vez con otro equipo de trabajo, conformado por un jefe de proyectos (que tiene una metodología) y un experto técnico con un framework de trabajo bien definido y consolidado para definir cada una de las partes de la solución, esta vez se toma mas en detalle a la solución, se toman decisiones que deben estar de acuerdo a la tecnología que vaya ser utilizada por el equipo de desarrollo y se define presupuesto y cronograma del proyecto (a esta altura ya debiera estar bien definido el equipo de trabajo del proyecto). Lo anterior en teoría, porque según mi experiencia, el arquitecto no se entromete en temas de presupuesto ni de cronograma del proyecto dado que el líder técnico (jefe de proyectos) debe conformar su equipo y planificar las actividades de su equipo, aunque esto puede variar dependiendo de las empresas cuando el arquitecto también es el jefe de proyectos.

Productos resultantes de la ingeniría de software:
No hay un consenso en cuanto al lenguaje y la forma en que el arquitecto entregue los elementos de ayuda a la toma de decisiones y que permitan la comunicación en un lenguaje común con todos los actores del proyecto. Acá, dependerá de la tendencia de la arquitectura escogida.
Uno de los modelos más usados y conocidos es el “4+1” de Philippe Kruchten, vinculado al Rational Unified Process (RUP), que define cuatro vistas diferentes:

• Vista lógica: describe el modelo de objetos.
• Vista de proceso: muestra la concurrencia y sincronía de los procesos.
• Vista física: muestra la ubicación del software en el hardware.
• Vista de desarrollo: describe la organización del entorno de desarrollo.
• Existe una quinta vista que consiste en una selección de casos de uso o de escenarios que los arquitectos pueden elaborar a partir de las cuatro vistas anteriores.

Ejemplos de Arquitectura de Software:
Para ilustrar y clarificar un poco lo anteior, se muestran dos diagramas de arquitectura en un entorno J2EE. Ambos diagramas están disponibles en Designing Enterprise Applications with the J2EE Platform, Second Edition de SUN.

El primer diagrama consiste en una vista lógica que muestra los componentes y servicios típicos de un entorno J2EE.
Por otro lado, en el modelo MVC tenemos una vista de procesos que se relacionan entre las capas Modelo, Vista y Controlador en un entorno J2EE.


Hasta acá lo mas relevante con respecto a la arquitectura. En otros post posteriores seguramente mencionaré temas asociados como SOA (Arquitectura orientada a servicios), Usabilidad y Patrones y antipatrones de diseño.

Recursos: The architecture journalist; revista del MSDN (Microsoft Development Network) especialmente dedicada a temas de arquitectura. Hay varios números en español aunque atrasados con respecto a las publicaciones en inglés.