Vistas de ejemplo de ArchiMate: Galería completa – Motivación, Estrategia, Negocio, Aplicación, Tecnología y Migración

Vista de marco

Vista de marco.

Esta vista representa el marco para construir todos los aspectos del desarrollo y los diagramas relacionados. La vista puede modificarse según la situación. Por lo tanto, esta vista puede usarse para navegar entre diagramas. Esta versión de la vista se aplica desde el marco ArchiMate (3). La motivación se introduce aquí como una «capa» en lugar de un «aspecto».

Punto de vista de motivación

Punto de vista de motivación

Punto de vista de motivación.

Esta vista puede usarse para analizar las motivaciones o impulsos que guían a la organización y su diseño o cambio en arquitectura empresarial. Estas analizadas de motivación son el punto de partida para todas las actividades de cambio o transformaciones empresariales dentro de la organización. La vista representa la visión del trabajo de desarrollo — ya sea que el alcance y la escala cubran toda la organización o una parte de ella (por ejemplo, una línea de negocio) o un único programa o proyecto (nivel de solución). Nota: Se puede agregar un Valor a, por ejemplo, Resultado (o cualquier otro elemento de ArchiMate) para indicar cuál es el verdadero valor añadido!

Los elementos de motivación se basan en el Modelo de Motivación Empresarial (BMM) [especificación v.1.3, 2015, OMG].

Vista de Misión – Visión – Valores

Misión – Visión – Valores.

Esta vista puede usarse para representar la misión, visión y valores centrales de la organización. La misión expresa, por ejemplo, «¿Cuál es el propósito de la organización, qué hace realmente o pretende hacer, y cuál es la razón principal de su existencia?». La visión es el estado futuro hacia el que la organización pretende desarrollarse. Los valores centrales son lo que apoyan la visión, moldean la cultura y reflejan los valores de la organización. Para realizar la visión de la organización, es necesario alcanzar objetivos estratégicos.

Referencia: Aldea, A. – Iacob, M.-E. – Hillegersberg, J. – Quartel, D. – Franken, H. (2015) Modelado de estrategia con ArchiMate.

Vista del mapa de valor estratégico

Mapa de valor – Vista del mapa estratégico.

Esta vista puede usarse para visualizar la estrategia de la organización. La vista contiene elementos de valor estratégico, y todas las actividades de desarrollo deben derivarse — directa o indirectamente — de estos elementos de valor estratégico. Al visualizar el valor estratégico, es posible rastrear todos los demás elementos relacionados con la ejecución estratégica real. Con esta vista, la estrategia puede volverse tangible: visualizada, comunicada y vinculada a la realidad.

Vista de análisis de partes interesadas

Vista de análisis de partes interesadas.

Esta vista puede usarse para el análisis de partes interesadas en el desarrollo empresarial: ¿cuáles son los impulsos del cambio? En primer lugar, se identifican las partes interesadas relevantes, luego se determinan los impulsos del cambio que se alinean con sus intereses. El concepto de «Evaluación» puede usarse para analizar los impulsos con más detalle, por ejemplo, según el enfoque SWOT (Fortalezas, Debilidades, Oportunidades, Amenazas). Normalmente, se pueden crear diferentes vistas de partes interesadas desde distintos puntos de vista. Otra razón para dividir la imagen general en partes más pequeñas es mantener los diagramas compactos y legibles — por simplicidad.

Punto de vista de partes interesadas

Punto de vista de partes interesadas.

Esta vista puede usarse para vincular los impulsos de las partes interesadas con los objetivos empresariales. Los objetivos son elementos clave del desarrollo de la organización. Todos los elementos posteriores deben remontarse a estos impulsos primarios de todas las actividades de cambio.

Vista de principios

Vista de principios.

Vista de riesgo y seguridad

Vista de riesgo y seguridad. Mapeo de conceptos de riesgo y seguridad a ArchiMate. Los problemas de seguridad y protección de datos forman parte de la gestión de riesgos. Este enfoque de modelado cubre ambos.

Referencias:

• Cómo modelar la gestión de riesgos empresariales y seguridad con el lenguaje ArchiMate®, The Open Group, Número de documento: W172, 2017.
• Modelado de la gestión de riesgos empresariales y seguridad con el lenguaje ArchiMate®, The Open Group, 2015.

Vista de análisis SWOT

Vista de análisis SWOT.

Vista de objetivos

Vista de objetivos (con elemento de valor).

Objetivos y resultados clave

Patrón OKR.

OKR es una estrategia de gestión popular para definir objetivos y rastrear resultados. Ayuda a crear alineación y compromiso alrededor de objetivos medibles. Los OKR tienen dos partes importantes: el objetivo que desea alcanzar y los resultados clave, que son la forma en que mide el logro del objetivo.

Objetivo:

• Una descripción cualitativa memorable de lo que desea lograr. Los objetivos deben ser breves, inspiradores y atractivos. Un objetivo debe motivar y desafiar al equipo.

Resultados clave:

• Un conjunto de métricas que miden su progreso hacia el objetivo. Debería tener de 2 a 5 resultados clave por objetivo. No demasiados, o nadie los recordará.

A continuación se muestra otra versión de OKR.

Patrón OKR (2).

Punto de vista de estrategia

Vista de capa de estrategia

Vista de estrategia

Vista de estrategia.

La versión 3 de ArchiMate ahora admite conceptos relacionados con la estrategia empresarial, como «Curso de acción», «Capacidad» y «Recurso», que pueden utilizarse para modelar la estrategia empresarial de una organización. El valor e importancia de esta vista radica en que los objetivos de la organización pueden vincularse a la estrategia, y en cómo se vinculan a la arquitectura empresarial a través de capacidades. Esta vista puede utilizarse para aplicar el «Modelado estratégico basado en objetivos» (Azevedo et al. 2015), en el que los objetivos forman una jerarquía, de modo que los objetivos de nivel superior pueden descomponerse en objetivos de nivel inferior.

Vista de estrategia empresarial

Estrategia empresarial.

Vista del Modelo de motivación empresarial (BMM)

Vista del Modelo de motivación empresarial (BMM).

Vista de requisitos

Vista de requisitos.

Esta vista puede utilizarse para recopilar requisitos basados en objetivos estratégicos. Esto vincula la estrategia con la realización: la estrategia puede rastrearse hasta la ejecución.

Vista de estrategia a capacidad

Vista de estrategia a capacidad.

Esta vista puede utilizarse, por ejemplo, para fines de Planificación basada en capacidades (CBP), así como para otros conceptos de ArchiMate como «Conductor» y «Objetivo», como se muestra en la figura a continuación. Esta vista puede utilizarse para apoyar propósitos de planificación estratégica (y ejecución). Por tanto, esta vista puede utilizarse para la fase de Estrategia a Capacidad, que puede incluirse en el «Estrategia a Portafolio» de IT4IT.

Vista de mapa de capacidades

Vista de mapa de capacidades.

Esta vista se puede utilizar para obtener una visión general de las capacidades de la organización: lo que la organización hace o puede hacer.

Vista de planificación de capacidades

Vista de planificación de capacidades.

Esta vista se puede utilizar, por ejemplo, para fines de planificación basada en capacidades (CBP), es decir, «el vínculo entre la estrategia y la arquitectura empresarial». La vista se puede utilizar, por ejemplo, para mapear la estrategia con las capacidades necesarias, y las capacidades con recursos y otros elementos constitutivos.

Vista de realización de capacidades

Vista de realización de capacidades.

Vista de realización de capacidades 2

Otra vista que define cómo se realizan las capacidades mediante qué elementos…

Vista de realización de capacidades 2.

Vista de flujo de valor

Vista de flujo de valor (patrón).

Nota: «asociación dirigida» utilizada al inicio de la cadena de valor / flujo de valor. Un flujo de valor puede constar de etapas de valor. Asimismo, un flujo de valor general y de alto nivel puede ser una «cadena de valor», que a su vez consta de flujos de valor. Por ejemplo, IT4IT (enlace) introduce una cadena de valor que consta de cuatro flujos de valor de la siguiente manera: Estrategia de cartera, Despliegue de demanda, Cumplimiento de solicitud, Detección-a-Corrección (enlace).

Vista de mapeo cruzado de flujo de valor y capacidades

A continuación se muestra un ejemplo sencillo de cadena de entrega de valor. Las cadenas de valor, redes de valor y flujos de valor se pueden modelar utilizando el elemento Flujo de valor de ArchiMate, incluido en la versión 3.1 de ArchiMate.

Vista de ejemplo de cadena de valor de idea a producción.

Cadena de entrega de valor. Este es un ejemplo ampliado que ilustra cómo las funciones apoyan (sirven) al flujo de valor. Esta vista se puede utilizar para definir lo que hace la organización (modelo de negocio), por qué se necesitan capacidades y cuál es su relación con la creación de valor.

Esta vista se incluye en la implementación de referencia del marco Lean EA (LEAF) (enlace). Navegue hasta «Flujos de valor», «Cadena de entrega de valor».

Vista del lienzo del modelo de negocio

Vista del modelo de negocio.

Esta es la forma básica del lienzo del modelo de negocio de A. OsterwalderLienzo del modelo de negocio (BMC), pero puede variarse según la situación. También existen enfoques versionados, como el «Lienzo del modelo de servicio» o el «Lienzo Lean». BMC se puede utilizar, por ejemplo, para el diseño y la innovación del modelo de negocio.

Modelar el BMC con ArchiMate «ayuda a rastrear los requisitos desde las necesidades del negocio hasta las especificaciones de diseño. Esto ayuda a descubrir el impacto de los cambios en el modelo de negocio sobre el diseño arquitectónico». [LO Meertens et al.]

El desarrollo general incluye soporte arquitectónico integrado para el análisis de estrategia y modelo de negocio. Esto permite a los analistas de negocios y desarrolladores observar, por ejemplo, cómo el modelo de negocio apoya la estrategia y cómo el modelo de negocio se adapta a la organización, y viceversa.

Si el BMC se modela en una herramienta de modelado, la ventaja de este enfoque es que todos los elementos del BMC pueden utilizarse en otras vistas dentro del mismo repositorio de modelos. Cuando se gira el modelo de negocio, todos los cambios son inmediatamente visibles. Los modeladores de negocios pueden crear nuevos elementos (por ejemplo, servicios) o utilizar todos los elementos existentes en el repositorio (por ejemplo, unidades organizativas o recursos).

Vista del Canvas de Conceptos

Canvas de Conceptos. El BMC puede tener diferentes variantes, como se muestra en la figura siguiente. El diseño de este Canvas de Conceptos es coherente con el enfoque por capas de ArchiMate.

Punto de vista de Negocios

Vista de la capa de Arquitectura de Negocios.

Vista del mapa de Servicios de Negocios

Vista de Servicios de Negocios.

Esta vista proporciona una visión general de los servicios de negocio de la organización. Esta vista puede utilizarse como un “catálogo de servicios” o “portafolio de servicios” para la gestión. Es muy importante identificar qué servicios de negocio ofrece la organización a sus clientes. Además, los servicios de negocio son el punto de partida para modelar todos los procesos y estructuras organizativas subyacentes. Por lo tanto, los servicios de negocio son uno de los elementos más importantes en la arquitectura empresarial.

Vista del mapa de Procesos de Negocios

Vista de Procesos de Negocios.

Esta vista puede utilizarse como un “mapa de procesos” que proporciona una visión general de los procesos de negocio de la organización.

Vista de Cooperación de Procesos de Negocios

Vista de Cooperación de Procesos de Negocios.

Esta vista puede utilizarse, por ejemplo, para modelar modelos operativos.

Vista del mapa de Actores de Negocios

Vista de Actores de Negocios.

Los actores de negocio pueden ser a) internos o b) externos. Los actores de negocio internos son, por ejemplo, unidades organizativas, mientras que los actores de negocio externos son, por ejemplo, clientes, socios comerciales u otros grupos de interesados que colaboran con la organización (por ejemplo, organizaciones del sector público u otras entidades reguladoras).

Vista de Cooperación de Actores de Negocios

Vista de Cooperación de Actores de Negocios.

Dos casos de uso son los siguientes:

1. Vista Intraempresarial: Punto de vista de Cooperación de Actores de Negocios que describe cómo cooperan los actores de negocio internos y cómo intercambian información.
2. Vista Interempresarial: Punto de vista de ecosistema que representa el entorno operativo en el que opera la organización. Un ecosistema es una red de organizaciones y socios comerciales que colaboran mediante interacciones colaborativas. Hay proveedores, subcontratistas y otros socios B2B, clientes, etc.

Vista de Proceso de Negocios

Vista de Proceso de Negocios.

Esta vista de proceso de negocio proporciona una “estructura y composición de alto nivel de uno o más procesos de negocio (o partes de ellos), donde se proporcionan servicios, se asignan actores a roles y se utiliza información en los procesos de negocio” [especificación ArchiMate 2.1]. El diagrama de proceso contiene elementos de “Unión” utilizados para modelar “ramificación” y “unión” en los flujos de procesos.

A continuación se muestra una vista de alto nivel del proceso. Esta se basa en el modelo operativo derivado del modelo de negocio, como se muestra en el diagrama de flujo de valor anterior.

Proceso de Idea a Producción.

SIPOC (Proveedores, Entradas, Proceso, Salidas, Clientes)

SIPOC.

La herramienta de Six Sigma llamada SIPOC (Proveedores, Entradas, Proceso, Salidas, Clientes) puede utilizarse para definir elementos comunes a todos los procesos. Se trata de una herramienta sencilla para analizar casos de negocio: ¿qué valor recibe el cliente y cómo lo recibe?

Vista del proceso de negocio con roles de negocio como “carriles” del proceso – Enfoque por capas

Vista de carriles del proceso de negocio (patrón) 2.0.

El “Rol de negocio A” representa al cliente, mientras que el carril superior representa la ruta del viaje del cliente.

¡Nota! Los pasos del proceso (actividades) están anidados dentro de los roles de negocio (visualizados como “carriles”), lo que significa: estos roles de negocio se asignan a estos procesos de negocio/pasos del proceso. Por tanto, esta vista es una combinación de una vista del proceso de negocio y una vista por capas.

La versión siguiente ilustra flujos de información y datos (relaciones de flujo). El carril superior representa la ruta del viaje del cliente (actividades relacionadas por relaciones de desencadenamiento).

Vista de carriles del proceso de negocio (patrón) 2.0 (flujo de información).

La versión siguiente representa un enfoque de diseño de servicios. El carril superior (Rol A) representa la ruta del viaje del cliente, que está conectado a la organización (Roles B y C) a través de servicios de negocio (1 y 2).

Vista de carriles del proceso de negocio (patrón) 2.0 (servicios).

Vista del proceso de negocio por capas

Vista por capas.

Esta vista puede utilizarse para modelar procesos de negocio que incluyen pasos manuales y automatizados.

Vista del mapa del viaje del cliente

Al analizar los viajes del cliente a un nivel alto, esta versión se crea utilizando elementos de motivación y estrategia.

Mapa del viaje del cliente (nivel alto).

Al analizar los caminos del servicio al cliente con más detalle, esta versión se crea utilizando elementos de capa de negocio y capa de aplicación (núcleo).

Vista del viaje del cliente (ejemplo) 1.0.

Esta vista centrada en el cliente se enfoca en la experiencia del cliente. Este enfoque de desarrollo “de fuera hacia adentro” relacionado con el “diseño de servicios” enfatiza el aspecto importante de que los servicios y productos se crean para brindar valor al cliente — y, de forma indirecta, a la organización misma. Las rutas del viaje del cliente pueden utilizarse para visualizar flujos de valor del cliente que abarcan múltiples servicios y aplicaciones de aplicación.

Vista del plano de servicio

Vista del plano de servicio 1 (servicios y flujos)

Esta vista está centrada en el cliente y en el servicio, pero también enfatiza la parte “de dentro hacia afuera” del servicio. Con la ayuda de este enfoque, el desarrollo impulsado por servicios puede identificar posibles impactos conductuales y estructurales sobre los servicios que se van a diseñar. Por tanto, esta vista complementa el enfoque impulsado por la experiencia del cliente a través de aspectos procesales y funcionales.

Esta vista tiene varias variantes. El ejemplo anterior se centra en los flujos de información entre capas y elementos.

Vista de la historia del usuario

Vista de la historia del usuario.

Esta vista puede utilizarse para visualizar historias de usuario.

Vista de modelos de servicios en la nube

Vista de modelos de servicios en la nube.

Vista de información

Vista de información.

La información puede modelarse a diferentes niveles de abstracción de la siguiente manera: a) nivel conceptual, b) nivel lógico y c) nivel físico. La figura anterior ilustra estos niveles de abstracción.

Vista del modelo de datos conceptual

Vista del modelo de datos conceptual.

La arquitectura de información de la EA incluye objetos de negocio utilizados en procesos de negocio, es decir, conceptos. Estos conceptos y sus relaciones pueden representarse en un modelo de datos conceptual.

Concepto de «Servicio»

Concepto de servicio.

El concepto de servicio a menudo es problemático y puede entenderse de muchas maneras diferentes. Para distinguir claramente los tipos de servicios involucrados, es buena práctica mencionar el prefijo: servicio de negocio, servicio de aplicación o servicio de tecnología. Según ITIL, los servicios de TI se relacionan con servicios de producción. Así. Los servicios de TI se corresponden más estrechamente con los servicios de aplicación.

Servicio frente a producto

Vista de producto.

El concepto de producto puede utilizarse como un elemento compuesto para agrupar servicios. Según la especificación ArchiMate:

«Un producto representa una colección de servicios coherentes y/o elementos estructurales pasivos, acompañados por un conjunto de contratos/acuerdos, ofrecidos en su conjunto a (clientes internos o externos).»

«Un producto puede agrupar o componer servicios de negocio, servicios de aplicación y servicios de tecnología, objetos de negocio, objetos de datos y objetos de tecnología, y contratos. Por tanto, un producto puede agrupar o componer elementos de capas distintas de la capa de negocio.»

«Puede asociarse valor a un producto. El nombre del producto suele ser el nombre utilizado en la comunicación con los clientes, o puede ser un sustantivo más genérico (por ejemplo, «seguro de viaje»).»

Punto de vista de aplicación

Vista de capa de arquitectura de aplicación.

Vista de mapa de servicios de aplicación

Vista de servicios de aplicación.

Vista de mapa de aplicaciones

Vista de mapa de aplicaciones.

Portafolio de aplicaciones, donde las aplicaciones pueden agruparse por unidad de negocio.

Vista de cooperación de aplicación (flujos de datos)

Vista de cooperación de aplicación.

Vista de integración de aplicación (relaciones dinámicas)

Se muestran varias formas alternativas de modelar el intercambio de datos entre aplicaciones en el ejemplo siguiente (del 1 al 10).

• «La aplicación A» posee el objeto de datos «A-1» solicitado por «la aplicación B».
• Los datos fluyen desde «la aplicación A» hasta «la aplicación B».
• «La aplicación A» realiza el servicio «A-1» utilizado por «la aplicación B».
• En la práctica, «la aplicación B» solicita la interfaz de aplicación «A-1» y recibe una respuesta…

Vista de integración de aplicación.

Vista de estructura de aplicación

Esta vista ayuda a diseñar o comprender la estructura principal de una aplicación y sus subcomponentes y datos relacionados. El diagrama puede utilizarse para descomponer la estructura del sistema de aplicación que se está construyendo para ilustrar la modularidad/descomposición: ¿cuáles son los subsistemas/subcomponentes, qué servicios de aplicación (o interfaces de aplicación) proporcionan?

Vista de la estructura de la aplicación.

Observe que los servicios de aplicación (figura superior) son funcionalidades comportamentales proporcionadas por interfaces estructurales (GUI y/o API en la figura inferior). Los servicios de aplicación y las interfaces de aplicación son «dos caras de la misma moneda».

Vista de la estructura de la aplicación 2.

Vista de la arquitectura de la aplicación

Esta vista combina enfoques de nivel de EA y nivel de solución, ya que tanto las aplicaciones como los módulos de aplicación existen en la misma vista.

Arquitectura de la aplicación.

Modelo de componentes de la aplicación (CM)

El Modelo de componentes de la aplicación 0-n es un método de modelado de arquitectura de aplicación que consiste en diagramas a diferentes niveles de abstracción, como sigue:

• En el nivel CM-0, el diagrama describe cómo la aplicación objetivo interactúa con su entorno y qué interacciones existen con aplicaciones adyacentes y usuarios. La aplicación objetivo se describe como una caja negra.
• En el nivel CM-1, la aplicación objetivo se descompone en módulos (componentes principales), y qué servicios de aplicación (o interfaces de aplicación) proporcionan y requieren estos módulos. La aplicación objetivo se describe como una caja blanca.
• En el nivel CM-2, los módulos se descomponen en subcomponentes. (El número de niveles necesarios depende de la situación.)

El diagrama del Modelo de componentes de la aplicación (CM) a continuación consta de componentes de aplicación y servicios de aplicación. Alternativamente, pueden usarse interfaces de aplicación en lugar de servicios de aplicación, dependiendo de la situación. Como siempre, es importante utilizar un estilo de modelado adecuado al propósito y modelar solo aquellos elementos que proporcionen información suficiente y aporten valor. Esto depende del modelador — si prefiere enfatizar aspectos funcionales o ser más específico y modelar, por ejemplo, interfaces reales con nombres precisos.

El diagrama del modelo de componentes a continuación consta de componentes de aplicación y servicios de aplicación. Alternativamente, pueden usarse interfaces de aplicación en lugar de servicios de aplicación.

Modelo de componentes de la aplicación – 0 (CM-0)

Modelo de componentes de la aplicación – 0.

El nivel Modelo de componentes – 0 (CM-0) (arriba) ilustra la interacción entre la aplicación objetivo y las aplicaciones adyacentes. Se introducen todos los servicios de aplicación relevantes (o interfaces de aplicación). El diagrama de nivel 0 consta de componentes de capa de arquitectura empresarial y sus servicios, con la aplicación objetivo en el centro.

Modelo de componentes de la aplicación – 1 (CM-1)

Modelo de componentes de la aplicación – 1.

El nivel Modelo de componentes – 1 (CM-1) (arriba) ilustra cómo se descompone la aplicación objetivo en módulos (o componentes principales), y qué servicios de aplicación (o interfaces de aplicación) realiza cada módulo. ¡Nota! Las aplicaciones externas pueden omitirse en este nivel, pero sus servicios (o interfaces) se muestran. Cuando se muestran más elementos de bajo nivel, se pueden/ deben omitar más elementos de alto nivel — para simplificar: mantenga el diagrama legible.

Modelo de componentes de la aplicación – 2 (CM-2)

Modelo de componentes de la aplicación – 2.

El nivel Modelo de componentes – 2 (CM-2) (arriba) ilustra cómo los módulos de la aplicación objetivo consisten en subcomponentes y cómo interactúan.

Vista de la función de la aplicación

Descomposición de funciones de la aplicación: ¿qué funciones contiene el sistema y qué servicios de aplicación proporciona?

Vista de las funciones de la aplicación.

Vista del proceso de la aplicación

Vista del proceso de la aplicación.

Vista del proceso de la aplicación – anidamiento.

Vista del proceso de la aplicación – internos.

Vista del diagrama de secuencia de componentes de la aplicación

Los diagramas de secuencia no están completamente dentro del alcance de ArchiMate, sino dentro de UML. Sin embargo, podemos modelar, por ejemplo, la secuencia de acciones realizadas por los componentes de aplicación utilizando ArchiMate, como se muestra a continuación.

Vista de secuencia de aplicación.

Las relaciones dinámicas «Desencadenar» y «Flujo» pueden utilizarse para modelar la dinámica entre componentes de aplicación. El diseño de esta vista puede parecerse al posicionamiento de un diagrama de secuencia de UML.

Vista de diagrama de secuencia de componente de aplicación 2

Esta versión (abajo) ilustra cómo ArchiMate puede utilizarse para modelar la secuencia de acciones realizadas por las partes internas de los componentes de aplicación. Las partes internas son, por ejemplo, a) procesos o funciones comportamentales y b) subcomponentes estructurales. Estos se modelan con elementos de Proceso de aplicación, Función de aplicación y Componente de aplicación. Aquí se muestran únicamente como alternativas.

Vista de secuencia de aplicación (2).

El flujo de operaciones en este diagrama de secuencia (arriba):

1. El subproceso «X» del componente de aplicación «A» envía un mensaje de solicitud con el parámetro «A» a la aplicación B.
2. El subproceso «B-1» del componente de aplicación «B» recibe la solicitud entrante y luego (de forma sincrónica) llama al componente de aplicación C, donde la función de aplicación «Y» recibe la solicitud, realiza algunas operaciones y responde.
3. Otro subproceso «B-2» del componente de aplicación «B» envía un mensaje con parámetros al componente de aplicación D y recibe una confirmación. El componente de aplicación «D» contiene subcomponentes que realizan procesamiento.
4. El componente de aplicación «A» recibe un mensaje de respuesta del componente de aplicación «B».

Como se muestra aquí, podemos modelar casos de integración bastante complejos combinando estos elementos (componentes de aplicación, procesos de aplicación y funciones de aplicación y relaciones (Desencadenar, Flujo)). Los diagramas de secuencia de UML tienen su uso especializado en el diseño de software, pero ArchiMate puede utilizarse para muchos propósitos de modelado – también para el diseño de aplicaciones.

La integración de aplicaciones es una de las partes más importantes de la Arquitectura Empresarial (EA). Por eso es beneficioso poder modelar con más detalle cómo las aplicaciones intercambian datos y qué mecanismos de interacción se utilizan. Una buena fuente para comprender mejor los patrones de integración es el libro «Enterprise Integration Patterns», aquí está el enlace.

La secuencia final del usuario añadida (abajo) sigue la misma idea de utilizar las relaciones dinámicas de ArchiMate Desencadenar y Flujo, que pueden utilizarse para modelar patrones de mensajería sincrónicos y asíncronos (solicitud-respuesta y devolución de llamada, así como publicar-suscribir, etc.).

Vista de patrón de secuencia.

Vista del proceso ETL

Vista del proceso ETL.

Vista de EAI / ESB

Vista de patrón EAI – ESB.

Vista en capas

Vista en capas.

La vista en capas puede utilizarse como un diagrama de contexto de visión general del área objetivo. La principal ventaja de esta vista es ilustrar el uso de las aplicaciones en los procesos de negocio y los servicios que proporcionan. La figura de arriba utiliza el elemento de agrupación de ArchiMate para modelar diferentes capas, mientras que la figura de abajo utiliza el elemento visual de grupo proporcionado por la herramienta (Archi).

En ArchiMate, hay básicamente tres (3) capas como sigue: 1) Capa de negocio, 2) Capa de aplicación y 3) Capa de tecnología. Sus colores suelen ser los siguientes: la capa de negocio es amarilla, la capa de aplicación es turquesa, la capa de tecnología es verde (véase el Marco Fundamental de ArchiMate, enlace).

Vista en capas.

Vista de aplicaciones y bases de datos

Las bases de datos son una unidad significativa en la arquitectura empresarial general de una organización. Por ejemplo, «Base de datos de clientes» o «Base de datos de clientes», «Base de datos de productos», etc. Alternativamente, una base de datos puede ser todas las tablas de una aplicación (por ejemplo, «tabla de clientes», «tabla de pedidos», «tabla de facturas», etc.), que juntas forman una sola base de datos. Según la especificación ArchiMate, el objeto de datos puede usarse para modelar bases de datos lógicas (figura siguiente), el Capítulo 9.4.1 «Objeto de datos» dice: «Ejemplos típicos de objetos de datos son registros de clientes, bases de datos de clientes o reclamaciones de seguros». «Una excepción importante es cuando un objeto de datos se utiliza para modelar una colección de datos, como una base de datos, donde solo existe una instancia». ArchiMate tiene un mecanismo integrado elegante que permite que ciertos conceptos se usen a diferentes niveles de abstracción (y detalle). Por lo tanto, por ejemplo, el objeto de datos puede usarse para modelar bases de datos lógicas, tablas de bases de datos, estructuras de mensajes (intercambiadas entre aplicaciones), etc.

Consideraciones sobre el modelado de bases de datos.

Base de datos como componente de una aplicación.

Niveles de abstracción de la base de datos.

Vista del modelo de datos.

Vista de casos de uso

ArchiMate puede usarse para analizar casos de uso desde la perspectiva funcional de las aplicaciones. Los casos de uso (conocidos en UML) pueden asignarse a servicios de aplicación, como se muestra en la figura siguiente.

Vista de casos de uso (patrón 1).

Los casos de uso pueden dividirse en: a) casos de uso empresariales y b) casos de uso del sistema (también conocidos como casos de uso del sistema). La figura siguiente ilustra cómo los «casos de uso principales» se modelan como servicios empresariales, y los casos de uso posteriores como servicios de aplicación.

Vista de casos de uso (ejemplo).

Cuando los casos de uso se identifican como servicios de aplicación, pueden usarse posteriormente como elementos funcionales de aplicaciones objetivo en otros diagramas (por ejemplo, en vistas por capas). En otras palabras: los servicios de aplicación representan el comportamiento (funcionalidad) de las aplicaciones. Para obtener información más detallada sobre el análisis de casos de uso, consulte el ArchiMate Cookbook, enlace.

Punto de vista tecnológico

Vista de capas de arquitectura tecnológica.

Vista de infraestructura

Esta vista representa la plataforma de las aplicaciones. Este patrón puede usarse para modelar la configuración del entorno de ejecución y el despliegue de las aplicaciones empresariales.

Vista de infraestructura.

Vista de infraestructura (anidada).

Vista de capa de implementación y migración / capa de arquitectura de transición

Vista de plan de implementación

Vista de plan de implementación.

Vista de tablero Kanban

Tablero Kanban (EA).

Kanban puede usarse para visualizar el trabajo y el flujo de trabajo. Kanban muestra, por ejemplo, cómo los requisitos de desarrollo, los epics, las historias de usuario, etc., fluyen desde el backlog hasta el estado listo (hecho). Kanban puede aplicarse a diversos usos según la escala y el alcance del caso de desarrollo. Por ejemplo, los «epics» pueden usarse a nivel de EA o las «historias de usuario» o «requisitos» a nivel de proyecto. La granularidad de los elementos de trabajo puede variar según la situación.

Vista genérica

Vista genérica.

Esta vista simplificada puede usarse, por ejemplo, como diagrama de contexto para un servicio, programa o proyecto específico.

Características adicionales

Visión general del contexto – Mapa de la Vía Láctea

Esta es un enfoque para visualizar la mayor cantidad posible en la misma vista. Para más detalles, véase el Mapa de la Vía Láctea para ArchiMate,enlace.

Mapa de la Vía Láctea FM (Nivel 2). (Nota: Este esquema de colores utiliza los colores predeterminados de ArchiMate. Pueden usarse otros colores según sea necesario.)

Vista de cooperación

Las capas pueden combinarse como se muestra en el ejemplo de diagrama de flujo de datos a continuación.

Vista de cooperación de aplicaciones (extendida).

Metamodelo

Metamodelo.