Archyno
ArchiMatePráctica del modelado

Los puntos de vista de ArchiMate

El modelo es una cosa; una vista es una ventana recortada en él para un público y una pregunta. Los puntos de vista son lo que impide que un modelo grande se convierta en un póster que nadie lee.

8 min de lecturaArchiMate 44 de 5

La respuesta corta

  • Un punto de vista es la especificación, una vista es un diagrama dibujado según ella. El punto de vista es la plantilla; la vista, la instancia.
  • El catálogo estándar son ejemplos trabajados, no un conjunto cerrado. El mecanismo importa más que la lista de nombres.
  • Elige a partir de la persona que va a leerlo y de la decisión que tiene que tomar, no de los elementos que tengas a mano.
  • Un punto de vista que admite todos los tipos de elemento no es un punto de vista, es el modelo. Nunca añadas elementos solo para que una vista quede bien.
Una vista de cooperación de aplicaciones de ArchiMate. Un componente CRM envía un flujo de fichas de cliente a un componente de administración de pólizas, que envía un flujo de liquidaciones a un componente de facturación. La administración de pólizas accede a un objeto de datos cliente, y un componente de almacén documental sirve a la administración de pólizas.
Una vista de cooperación de aplicaciones. Una capa, una pregunta - qué sistemas intercambian qué - y deliberadamente nada sobre los procesos de negocio de arriba ni sobre los servidores de abajo.

01El modelo no es el dibujo#

Esta es la idea sobre la que está construido ArchiMate y la que más se le escapa a quien llega de una herramienta de dibujo. Hay un modelo: un conjunto de elementos y las relaciones entre ellos, almacenado una vez. Una vista es una selección de ese modelo, dispuesta con un propósito. El mismo componente de aplicación aparece en seis vistas y sigue siendo un elemento: renómbralo y las seis cambian.

Un punto de vista es la receta con la que se hace una vista: para qué interesados es, qué preocupación aborda, y qué tipos de elemento y de relación se permiten en ella. El punto de vista es la definición; la vista es una instancia suya.

02Un modelo, dos vistas#

Dos vistas sobre el mismo modelo. A la izquierda, una vista en capas: un proceso de gestión de siniestros servido por un servicio de aplicación de registro de siniestro, servido a su vez por un nodo de clúster de siniestros. A la derecha, una vista de cooperación de aplicaciones: administración de pólizas fluyendo hacia facturación, con la administración de pólizas realizando el servicio de registro de siniestro.
El registro de siniestro es un solo elemento y aparece en ambas. La vista de la izquierda responde a una pregunta de dependencia, la de la derecha a una de integración, y ninguna es un subconjunto de la otra.

Fíjate en lo que deja fuera cada vista. La vista en capas no tiene nada que decir sobre la facturación; la de cooperación no tiene nada que decir sobre el clúster en el que corre el software. Ambas omisiones son el asunto: una vista que lo incluyera todo no respondería bien a ninguna de las dos preguntas.

Por eso también los puntos de vista y las relaciones derivadas trabajan juntos. La vista en capas muestra el clúster sirviendo al proceso directamente, que es una derivación de una cadena más larga guardada en el modelo. El público recibe la respuesta corta; el modelo se queda con la larga.

03Los puntos de vista estándar#

La especificación define un catálogo de ellos. No hace falta memorizarlo, pero conviene saber a grandes rasgos cuáles existen, porque echar mano de un punto de vista con nombre es más rápido que inventar una disposición y produce una vista que otros arquitectos reconocen de un vistazo.

ElementoNotaciónQué significa
En capastodas las capas, una columnaLa panorámica. Negocio sobre aplicación sobre tecnología, con la cadena de servicio y realización entre ellas. La que se dibuja primero y la que la dirección de verdad mira.
Cooperación de aplicacionescomponentes y los flujos entre ellosEl paisaje de integración. Qué habla con qué, y qué se mueve. La vista en la que vive un equipo de integración.
Uso de aplicacionesservicios encontrándose con procesosQué procesos de negocio dependen de qué servicios de aplicación. La vista de análisis de impacto.
Tecnologíanodos, redes, artefactosLa infraestructura en sus propios términos, para quienes la operan.
Proceso de negocioprocesos, roles, eventosLa cadena de procesos con los roles asignados. Donde un lector esperaría si no BPMN, y donde a menudo debería recibir BPMN.
Motivacióninteresados, impulsores, objetivosEl porqué. Los interesados, qué les empuja, y los objetivos en juego.
Realización de objetivosde objetivos hasta requisitosLa cadena desde un objetivo abstracto hasta los requisitos concretos que deben lograrlo. Útil para las discusiones de alcance.
Implementación y migraciónpaquetes de trabajo, mesetas, brechasLa hoja de ruta, expresada como arquitectura y no como diagrama de Gantt.
Mapa de capacidadescapacidades anidadasLo que la organización sabe hacer, independientemente de quién lo haga o qué lo sostenga. El punto de partida de las conversaciones de estrategia.

Nueve del conjunto estándar, elegidos porque cubren la mayor parte del trabajo real. El catálogo completo está en la especificación y el resto son variaciones de estos.

04Elegir uno para un público#

Un punto de vista se define por un interesado y una preocupación, así que elegirlo empieza por una frase de la forma "X necesita decidir Y". Si no puedes terminar esa frase, la vista no tiene público y no debería dibujarse.

ElementoNotaciónQué significa
Patrocinador ejecutivoen capas, mapa de capacidadesQuiere la forma del conjunto y adónde va el dinero. Doce elementos como mucho, sin detalle de tecnología.
Arquitecto de integracióncooperación de aplicacionesQuiere interfaces y qué las cruza. Flujos etiquetados, siempre.
Responsable de infraestructuratecnología, despliegueQuiere nodos, redes y qué está desplegado dónde.
Product owneruso de aplicaciones, proceso de negocioQuiere saber en qué sistemas se apoya su proceso.
Director de programaimplementación y migraciónQuiere mesetas, brechas y paquetes de trabajo, en ese orden.

05Definir los tuyos#

El conjunto estándar es un punto de partida y la especificación espera que le añadas. Un punto de vista propio merece definirse cuando la misma vista filtrada se dibuja a mano una y otra vez: una vista de "sistemas dentro del alcance de la migración", por ejemplo, o de "qué toca datos personales".

Úsalo cuando

  • La misma selección de tipos de elemento se dibuja una y otra vez para el mismo público
  • Una pregunta de cumplimiento o auditoría necesita una vista repetible y defendible
  • Un dominio tiene vocabulario que los puntos de vista estándar no sacan a la superficie
  • Quieres una vista que una herramienta pueda regenerar en vez de una que alguien mantiene

Usa otra cosa cuando

  • Sería el punto de vista en capas con dos tipos de elemento más: usa ese
  • El problema real es que el modelo es demasiado grande, no que las vistas estén mal
  • Nadie ha hecho la pregunta que el punto de vista respondería
  • La definición permitiría todos los tipos de elemento, que no es un punto de vista

Escribe la definición: nombre, interesados, preocupación, tipos de elemento permitidos, tipos de relación permitidos. Un punto de vista que solo existe como costumbre en la cabeza de un arquitecto produce vistas que se separan en silencio, que es justo el problema para el que se introdujeron los puntos de vista.

En una línea cada uno

  1. 01Un modelo, muchas vistas; un punto de vista es la receta con la que se hace una vista.
  2. 02Una vista se define por un interesado y una preocupación: nombra ambos o no la dibujes.
  3. 03Lo que una vista deja fuera es tan deliberado como lo que muestra.
  4. 04Empieza por el punto de vista en capas; es el que leen los no arquitectos.
  5. 05Las relaciones derivadas dejan que una vista muestre la respuesta corta sin perder la larga.
  6. 06La única vista de todo es un síntoma, y dividir por público es la cura.

06Preguntas frecuentes#

¿Qué diferencia hay entre una vista y un punto de vista en ArchiMate?

Un punto de vista es la especificación: qué tipos de elemento y de relación se admiten, y a qué parte interesada y preocupación se dirige. Una vista es un diagrama concreto dibujado según esa especificación. El punto de vista es la plantilla, la vista es la instancia.

¿Cuáles son los puntos de vista estándar de ArchiMate?

La especificación define un catálogo que incluye, entre otros, el punto de vista por capas, la cooperación de aplicaciones, el uso de la tecnología, la cooperación de procesos de negocio, la realización de servicio y la realización de objetivo. Son ejemplos trabajados más que un conjunto cerrado, y el mecanismo importa más que la lista.

¿Puedo definir mi propio punto de vista de ArchiMate?

Sí, y la especificación lo espera. Un punto de vista propio nombra a sus partes interesadas, sus preocupaciones, y los tipos de elemento y relación que admite. Lo que no debes hacer es añadir al modelo elementos que existen solo para que una vista quede bien.

¿Cómo elijo un punto de vista?

Empieza por la persona que va a leerlo y por la decisión que tiene que tomar. Un punto de vista que admite todos los tipos de elemento no es un punto de vista, es el modelo, y un diagrama que lo enseña todo no responde a nada.

CompartirXLinkedIn
↑ Volver arribaTodos los artículos: ArchiMate →
En esta serie
  1. 01Qué es ArchiMate
  2. 02Capas y aspectos
  3. 03Relaciones
  4. 04Puntos de vista
  5. 05ArchiMate con IA

Lecturas relacionadas

← Todos los artículos