Tipos y niveles de la Arquitectura

Es común percibir la confusión entre distintos tipos y niveles de Arquitectura. Es muy frecuente, por ejemplo, que se nombren a especialistas en aplicaciones para el rol de Arquitecto de Soluciones, asumiendo que su responsabilidad se centra principalmente en las integraciones. 

Voy a exponer mi forma de entender los distintos niveles de Arquitectura acudiendo a la experiencia que seguramente muchos viven en su día a día.

 

Arquitectura Técnica

 

Desde el punto de vista de TOGAF, siempre me he desempeñado en dos dominios de la Arquitectura técnica: aplicaciones y tecnología. Recordemos que varios frameworks y metodologías la dividen en 3 que resumo a 10 mil pies de altura:

 

• Arquitectura de Datos: De acuerdo a ADM se desarrolla en la fase C, Arquitectura de sistemas de información. Describe la estructura de los datos físicos  y lógicos de una organización. Su utilidad radica en habilitar el gobierno de los datos generados y almacenados, haciendo recurrente la práctica en cada proyecto de arquitectura. Es común que se empleen frameworks como DAMA para lograr este propósito.

• Arquitectura de Aplicaciones: Al igual que la anterior, se desarrolla en la fase C, Arquitectura de sistemas de información. Se centra en identificar y documentar la interacción a nivel de software entre aplicaciones, plataformas y en general los sistemas de información. Es común que se genere un mapa de funciones de aplicación vs funciones y procesos de negocio que soportan estas aplicaciones al que se denomina blueprint. Al igual que los datos, los sistemas deben ser gobernados. Entender qué capacidades expone cada sistema de información y cómo interactúan hace posible realizar ejercicios racionales de comprar, hacer o reusar cada vez que se ejecute un proyecto de arquitectura. 

• Arquitectura Tecnológica: Se desarrolla en la fase D, Arquitectura de tecnología. Se centra en la infraestructura y la seguridad describe, por tanto, la interacción de los dispositivos físicos y elementos de hardware sobre los cuales se despliegan los sistemas de información y se habilitan funciones tecnológicas. Aborda un amplio espectro físico y lógico, entre servidores, dispositivos de red, dispositivos de IoT, sensores, políticas de control de acceso, etc. 

 

Arquitectura de negocio

 

Por otro lado, creo que podemos estar de acuerdo en que los usuarios funcionales suelen conocer mucho mejor el negocio, interpretan la experiencia de usuario de acuerdo a su propia interacción y la de sus colegas con los sistemas de información y además reconocen las oportunidades de mejora de los procesos y las aplicaciones. En general, son los usuarios funcionales o sus jefes, directores de segmento de negocio o de producto,  los que en un proyecto cubren el rol de product owner.

 

Debido al conocimiento que tienen estos actores acerca del negocio y en el mejor de los casos, con el apoyo del área de proceso, es común que se encarguen de definir, modelar y proponer la optimización en las funciones y procesos. En ausencia de un Arquitecto de negocio, he sido testigo de que esta practica se generaliza.

 

De acuerdo a TOGAF, la Arquitectura de negocio se encuentra fuera del ámbito de la Arquitectura técnica. Permite hacer visible y gobernar la relación entre la estrategia y la operación. En otras palabras describe la relación entre objetivos estratégicos con las funciones y procesos que los soportan. Su práctica favorece la optimización de los modelos de negocio al intervenir las variables que giran alrededor, entre otros: costos, tiempos, experiencia, personas, etc. En un ejercicio de Arquitectura Empresarial, es el primer dominio a trabajar; fase B de ADM.

 

Arquitectura de Solución

 

Una solución se enfoca en la implementación, describe cómo se resuelve una capacidad en particular. De acuerdo a TOGAF,  La unión de dos o más Solution Building Block (la red, el proceso, la entidad de negocio, la aplicación) soportan una capacidad descrita por un Architecture Building Block (servicios de cartera, servicios de cliente, servicios de linea de producción, etc). A nivel de arquitectura, la especificidad es la misma, la Arquitectura empresarial identifica las distintos brechas requeridas para llevar la organización a un estado deseado, cada transición se conforma de proyectos de implementación traducidos, cada uno, en una Arquitectura de solución.

 

En resumen

 

La Arquitectura Empresarial se expande a toda la organización, genera las brechas requeridas para llevarla a un estado deseado. Para lograrlo, cada brecha o transición se conforma de un conjunto de proyectos priorizados y estructurados a través de la Arquitectura de Solución. A su vez, cada Arquitectura de solución estará conformada de uno o más de los diferentes dominios: Arquitectura de negocio, datos, aplicaciones y/o tecnología. Adicionalmente, una Arquitectura técnica puede ser de datos, tecnología o aplicación y finalmente,  tanto datos como aplicación hacen parte de la Arquitectura de sistemas de información.

 

Tal vez, el siguiente modelo conceptual podría ayudar a comprender cómo interpreto la relación semántica entre los distintos niveles de la arquitectura: 

Referencias:

1. http://www.opengroup.org/public/arch/p4/bbs/bbs_adm.htm. Building Blocks and the Architecture Development Method
2. https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap02.html. Core concepts