miércoles, 26 de junio de 2013

¿Qué es arquitectura de sistemas de información?

La ambigüedad en la definición del rol del arquitecto y el rol de la  arquitectura en los proyectos de sistemas de información ha generado y  genera múltiples controversias, rechazos y mal entendidos. Es común, por ejemplo, encontrar controversias por la diferencia entre arquitectura y diseño de sistemas,  y por el valor del rol del arquitecto dentro de un proyecto de implementación. Muchas de las controversias se han dado por la visión que la industria ha creado del arquitecto como alguien alejado de las realidades de implementación de los proyectos, que solo se encarga de crear conceptos de alto nivel que luego no son aplicables.

En este artículo exploramos definiciones de la industria para estos conceptos y fijamos posiciones sobre el rol real que deben desempeñar los arquitectos de sistemas y su valor en los proyectos de implementación.

Arquitectura de sistemas

Para iniciar las discusión partamos de la definición de un sistema como un conjunto de componentes interconectados que interactuán para cumplir con un propósito. Esta definición, incluye los sistemas que tienen componentes de software, componentes de hardware, procesos y actores humanos o artificiales para llevar a cabo sus propositos. En este sentido un sistema se refiere a cualquier cosa natural o artificial en la que estemos interesados, por ejemplo, el cuerpo humano, una ciudad, la economía o un sistema de información.

A partir de esta concepción de sistema podemos parafrasear la definición de arquitectura que se da en el estándar IEEE 1471 (Este estándar fue luego remplazado por el ISO/IEC/IEEE 42010, sin embargo preferimos las definiciones originales encontradas en el 1471, porque las consideramos menos ambiguas), así la definición de arquitectura es la siguiente:

Arquitectura: es la organización fundamental de un sistema encarnada por: sus componentes, las relaciones entre estos y con su entorno, y los principios que gobiernan su diseño y evolución.

Esta definición presenta dos elementos importantes. el primer elemento, se refiere al uso de la palabra "sistema" de manera genérica para que sea remplazada luego por el sistema de interés, ya sea un sistema de software, un sistema de hardware , un sistema de sistemas o una empresa. El segundo elemento, es la separación directa de la arquitectura de un sistema y la descripción de esta arquitectura. Es decir, la definición plantea que todo sistema tiene una arquitectura, así esta no se haya documentado. Igualmente, es importante destacar que la definición claramente plantea que la arquitectura de un sistema incluye y determina los principios de diseño y evolución, así estos no estén documentados.

El rol del arquitecto

Ya que tenemos una definición de arquitectura pasamos a definir el rol del arquitecto. Tomamos como punto de partida  la definición de arquitecto obtenida del diccionario Merriam-Webster en línea:

"Definition of ARCHITECT
1 : a person who designs buildings and advises in their construction
2 : a person who designs and guides a plan or undertaking <the architect of American foreign policy>
...

Origin of ARCHITECT
Middle French architecte, from Latin architectus, from Greek architektōn master builder, from archi- + tektōn builder, carpenter — more at technical
First Known Use: 1563"

La definición anterior ya muestra elementos relevantes para encontrar una definición de arquitecto de sistemas. El primer elemento es que el arquitecto es el que diseña edificios y asesora en su construcción (insinuando una relación directa entre el diseño y la arquitectura). El segundo elemento es el origen etimológico de la palabra "arquitecto", el cuál viene de maestro constructor o maestro carpintero. Estos dos elementos nos dan pie a dar una definición concreta del rol de arquitecto de sistemas de información:

Arquitecto: Persona o grupo de personas formadas, capacitadas y licenciadas para planear, diseñar y supervisar la construcción de sistemas.

Esta definición se aleja de la visión del arquitecto de "alto nivel" y le da un rol activo en todas la etapas de implementación de un sistema de información. Igualmente, esta definición se aleja de la visión que le da un rol de generador de documentos que no son luego consumidos en los proyectos de implementación.

Es de anotar que un error muy común en los proyectos de implementación de sistemas de información es considerar al arquitecto como una persona. En nuestra experiencia el rol de arquitecto es completado por múltiples personas, entre las cuales hay gente del negocio, gerentes de proyectos e ingenieros de sistemas. Y es muy importante resaltar que el rol de arquitecto puede ser desempeñado  por un equipo.

Para terminar esta discusión sobre el rol del arquitecto mencionó una de las características que muchos autores han identificado como fundamental en el rol del arquitecto. Esto es la responsabilidad de encontrar un consenso entre múltiples interesados (stakeholders), ya sean de negocio, técnicos o externos al sistema.

Conclusiones y lecturas sugeridas

En este artículo discutimos el concepto de arquitectura y el rol del arquitecto. La arquitectura la definimos como una característica intrínseca de todo sistema que esta encarnada en sus componentes, sus relaciones y los principios que gobiernan su diseño y evolución. En la definición hacemos una separación de la arquitectura de un sistema y la descripción de esa arquitectura. Respecto al rol de arquitecto, aclaramos que en la mayoría de proyectos este rol se ejecuta por un equipo  y definimos el rol como la persona o grupo de personas formadas, capacitadas y licenciadas para planear, diseñar y supervisar la construcción de sistemas.

En el artículo adoptamos una visión práctica del arquitecto y de la arquitecta, buscando siempre describir conceptos que son fácilmente aplicables a la realidad diaria de proyectos de implementación de sistemas de información. Por esto, nos alejamos de la visión del arquitecto de "alto nivel" que todo lo controla y diseña, y adoptamos una visión más dinámica y comprometida con el éxito de los proyectos. Igualmente, nos alejamos de la visión del arquitecto documentador que tanto daño le ha hecho a la práctica del arquitecto de TI.

Para terminar les recomiendo un libro  y un artículo. El libro es "The Process of Software Architecting" de Peter Eeles y Peter Cripps (enlace del libro en amazon). El libro es escrito por ingenieros de IBM (™) con amplia experiencia, y evita muchas de las confusiones y discusiones inocuas que otros autores han generado por las descripciones ambiguas sobre la arquitectura y la documentación de arquitecturas. Respecto al artículo, es una reseña sobre una interesante discusión entre Vivek Kundra, el CIO de Estados Unidos en 2012,  y Zachman, el creador de un reconocido framework para arquitectura empresarial. El tema de la discusión es la documentación innecesaria e impráctica que algunos han asumido como rol de los arquitectos empresariales (enlace al artículo).

2 comentarios:

  1. Interesante tema, cabe adicionar que la aplicabilidad de diseño, administracion y resultados lo da en gran medida la experiencia segun vertical donde se aplique.

    ResponderEliminar