1

Ingeniería de Sistemas y Computación

ISIS-2403 Arquitectura Empresarial y de Solución

Monitoria Archimate

Tutorial BizzDesign

En este tutorial vamos a desarrollar diagramas de Archimate en la herramienta BizzDesign basados en un caso de ejemplo denominado ArchiSurance. Se desarrollarán los siguientes modelos:

Business function viewpoint

Organization viewpoint

Application Structure Viewpoint

Business Process Co-operation Viewpoint

Application Usage Viewpoint

Application Behaviour Viewpoint

Infrastructure Viewpoint

Diagrama de relación entre aplicaciones lógicas y artefactos físicos

Al final del documento se puede encontrar un resumen de todos los elementos utilizados en este tutorial. Para obtener la especificación de todos los elementos de Archimate, referirse a la especificación de Archimate 1.0.

Caso de ejemplo: ArchiSurance

ArchiSurance, a (fictious) company that originally provided home and travel insurance, has merged recently with two other insurance companies, PRO-FIT (car insurance) and LegallyYours (legal aid). To create insight in ArchiSurance‟s primary operations, the company is described in terms of its main business functions:

Maintaining Customer Relations and Intermediary Relations: these business functions are responsible for the contacts of ArchiSurance with its customers and the intermediaries that sell its products. It handles customer questions and incoming claims, and performs marketing and sales.

Contracting: this function does the „back-office‟ processing of contracts. It performs risk analysis and ensures legally and financially correct contracts.

Claims Handling: this function is responsible for handling insurance claims.

Financial Handling: this function performs the regular premium collection, according to the insurance policies with customers as produced by Contracting, and handles the payment of insurance claims.

Asset Management: this function manages the financial assets of ArchiSurance, e.g. by investing in stocks and bonds.

These business functions are very similar for most insurance companies and represent what is most stable about an enterprise.

El texto describe las funciones de negocio de ArchiSurance. Para modelar las funciones empleamos el Business Function Viewpoint. En esta vista se relacionan funciones con roles y actores de negocio.

Para crear la funciones de negocio descritas previamente, seleccionamos New > Business functions e ingresamos como nombre “Functions”. Esto crea una agrupación de funciones.

2

Ahora creamos las funciones dentro de la agrupación ingresando en New multiple > Business function.

Cada función que se define puede tener atributos. En este caso vamos a adicionar el atributo de documentación para ingresar información acerca de la función.

3

Se ingresan los nombres e información de las funciones de negocio.

Al finalizar, se deben poder observas las funciones en la vista de Models.

Adicionalmente, creamos los roles de negocio identificados. Para ello debemos crear la agrupación de actores primero ingresando en New > Business actors.

4

Ahora podemos crear los roles ingresando en New multiple > Business role.

Ingresamos los nombres y descripciones de los roles.

5

Ahora creamos la Business Function View e ingresamos por nombre “Functions view”.

Damos doble click a la vista para abrir el diagrama. Seleccionamos las funciones de negocio y las arrastramos al diagrama.

De igual forma, seleccionamos los roles y los adicionamos al diagrama.

6

Organizar los elementos de manera que tenga la siguiente disposición:

Ahora vamos a adicionar las relaciones. La vista de funciones de negocio utilizan relaciones de flujo para indicar el flujo de información entre roles y funciones. Esta relación se llama Flow relation.

7

El diagrama final es el siguiente:

Post-merger integration is in full swing. The first step in the integration process has been the creation of a unified front office, comprising departments for managing relations with customers on the one hand, and

8

intermediaries on the other hand. However, behind this front office are still three separate back offices:

Home & Away: this department was the original pre-merger ArchiSurance, responsible for home and travel insurance.

Legal Aid: this is the old LegallyYours, responsible for legal aid and liability insurance.

Car: this department is the core of the old PRO-FIT and handles car insurance, including some legal aid.

Furthermore, ArchiSurance is in the process of setting up a Shared Service Center for document processing, which will handle all document streams and performs scanning, printing, and archiving jobs.

La estructura de la organización se modela con el Organization Viewpoint. Este punto de vista modela la estructura interna de la organización, relacionando actores, roles, interfaces y colaboraciones de negocio. En primera instancia debemos crear los actores. Dentro de la agrupación de actores creada previamente, seleccionamos New multiple > Business actor.

Ahora debemos crear la Organization structure view que denominaremos “Structure view”. En ella adicionaremos los actores creados previamente y los organizamos hasta obtener el siguiente diagrama:

9

As in many recently merged companies, IT integration is a problem. ArchiSurance want to move to a single CRM system, separate back-office systems for policy administration and finance, and a single document management system. However, Home & Away still have separate systems for the policy administration and the financial handling of premium collection and claims payment, and use the central CRM system and call center. The Car department have their own monolithic back-office system, but use the central CRM system and call center. The Legal Aid department have their own back- and front office systems.

El texto describe las aplicaciones que se usan en la empresa y como se relacionan entre sí. Esto hace referencia al Application Structure Viewpoint. Este punto de vista relaciona interfaces, componentes y colaboraciones de aplicaciones, data objects, y el acceso entre ellos. Para ello creamos una agrupación de aplicaciones, New > Applications. Dentro de este grupo creamos las aplicaciones seleccionando New multiple > Application component.

Ahora debemos crear la Application structure view que denominaremos “Application structure view”. En ella adicionaremos las aplicaciones creadas previamente.

10

Existe un elemento de relación que se llama Grouping el cual se usa para agrupar otros elementos con características similares. Vamos a utilizar este elemento para agrupar las aplicaciones.

11

Ahora vamos a adicionar las relaciones de flujo entre aplicaciones.

NOTA: Para curvar las relaciones se debe mantener presionada la tecla CTRL al tiempo que se arrastra la flecha.

An important prerequisite for the changes in ArchiSurance‟s IT is that the IT integration should be “invisible” to ArchiSurance‟s clients: products & services remain the same. However, this is not a

12

straightforward requirement. To illustrate the complexity of the relationships between products, business processes and IT support, the next figures show the services provided by the Handle Claim business process, the relations between this business process and its supporting IT applications, and how a single service of these applications is realized. Note that this only shows these relations for a single business process. In general, many different business processes within the back office link the external products and services with the internal systems. This web of relations creates a major problem if we want to create insight in the IT support of ArchiSurance.

El texto describe 3 diagramas Archimate: Business Process Co-operation Viewpoint, Application Usage Viewpoint and Application Behaviour Viewpoint. El punto de vista de cooperación de procesos de negocio modela eventos, procesos, roles, actores, colaboraciones, servicios, interacciones y objetos de negocio; representaciones de los objetos; y servicios de aplicaciones. Para este punto de vista tenemos que crear procesos: creamos el grupo de procesos, New > Business processes, que denominaremos “Processes”; y dentro de él, New multiple > Business process.

Ahora debemos crear un evento dentro del grupo de procesos. Para ello ingresamos en el menú New > Business event y le damos por nombre “Damage ocurred”. Por último, debemos crear los servicios de negocio. Primero se debe crear el grupo de productos de negocio ingresando en New > Business products y le ponemos por nombre “Products”. Una vez creado el grupo de productos, creamos los servicios de negocio a través del menú New multiple > Business service.

Ahora debemos crear el Business process cooperation view que denominaremos “Process cooperation view”. En él adicionamos los procesos creados y los organizamos de la siguiente forma:

13

A continuación adicionamos el evento creado, el rol “Customer” y los servicios de negocio.

Ahora adicionamos las relaciones. Este diagrama usa 3 tipos de relaciones: Realization, Triggering y Used by. La relación de realización indica que el proceso es realizado por el servicio, la relación de trigger indica que ese evento o proceso arranca el siguiente, y la relación de usado indica que el rol es usado por el servicio.

El punto de vista de uso de aplicaciones modela eventos, funciones, roles y objetos de negocio; componentes, servicios e interfaces de aplicación; y data objects. Para este punto de vista vamos a crear servicios de aplicación. Para ello, dentro del grupo de aplicaciones, seleccionamos New multiple > Application service.

14

También debemos crear una nueva aplicación denominada “Document management system”. Para crear el punto de visa de uso de aplicación emplearemos un Total view que denominaremos “Application usage view”. Adicionamos los procesos; los servicios de aplicación creados previamente; y las aplicaciones “Document management system”, “CRM application”, “Home & away policy administration”, “Home & away financial application” y “Bank system”. Nótese que los procesos ya vienen conectados, esto se debe a que la aplicación reutiliza las conexiones que ya se han creado entre elementos en otras vistas. En este caso vamos a mantener estas relaciones.

A continuación agregamos las relaciones entre los elementos y agrupamos los servicios. Las relaciones que se emplean son Realization, Used by y Triggering.El diagrama resultante es el siguiente:

15

Ahora vamos a desarrollar el Application behaviour view. Este punto de vista modela servicios, funciones, interacciones, interfaces, componentes y colaboraciones de aplicación; y data objects. Primero creamos las funciones de aplicación dentro del grupo de aplicaciones, ingresando en New multiple > Application function.

Debemos crear un servicio de aplicación “Policy creation service” y los data objects “Insurance request”, “Insurance policy” y “Customer file”. Para la creación de los data objects es necesario crear primero un grupo de tipo “Application data” que tendrá el mismo nombre.

16

Ahora creamos una “Application behaviour view” que denominaremos bajo el mismo nombre. Adicionamos los data objects creados previamente, el servicio “Policy creation service”, la aplicación “Home & away policy administration” y las funcionalidades de aplicación creadas.

Debemos adicionar las relaciones correspondientes. Este diagrama utiliza relaciones de Access, Triggering y Realization. La relación de acceso indica que esa función accede a ese tipo de dato.

17

The infrastructure on which the applications are deployed is a hybrid of traditional mainframe processing and more recent additions in the form of a server farm of Unix blade servers. A Network Attached Storage (NAS) server is used by the Unix machines, whereas the mainframe runs the usual system software such as a DBMS, message queuing middleware, and a CICS environment. The ArchiSurance network is connected to the intermediaries via the Internet, of course with the appropriate firewalling. Onto this infrastructure, the various logical applications are deployed in the form of physical artifacts such as EJBs.

El texto describe dos tipos de diagramas: Infrastructure Viewpoint y un diagrama que relaciona aplicaciones lógicas y artefactos físicos. El punto de vista de infraestructura modela servicios e interfaces de infraestructura, artefactos, rutas de comunicación, redes, nodos, dispositivos y sistemas de software. Primero crearemos los dispositivos por lo que crearemos el grupo de infraestructura: New > Infrastructures. Luego crearemos los dispositivos en el menú New multiple > Device.

Ahora debemos crear los nodos, redes y sistemas de software. Para ello ingresamos al menú New multiple > Node, New multiple > Network y New multiple > Software system.

Ahora debemos organizar los elementos de acuerdo a la forma en qué queremos que se muestre en el diagrama. Para crear el diagrama de infraestructura ingresamos en el menú New > Infrastructure view que denominaremos bajo el mismo nombre. Luego adicionamos los elementos de infraestructura creados previamente.

18

Para terminar el diagrama, debemos agrupar los componentes y adicionar las relaciones. Este diagrama utiliza relaciones de asociación o Association.

Para finalizar, desarrollaremos el diagrama de relación de aspectos lógicos y físicos. Para ello crearemos los artefactos (grupo de infraestructura) en el menú New multiple > Artifact. Adicionalmente, debemos crear las aplicaciones (grupo de aplicaciones) en el menú New multiple > Application component.

19

Crearemos este diagrama empleando un Total view que denominaremos “Mapping of logical/physical components” y adicionaremos los elementos.

Adicionamos las agrupaciones y relaciones correspondientes. Las relaciones a utilizar son Realization y Association.

20

Resumen de notación

Concepto Descripción Notación

Business Layer

Business function A unit of internal behavior that groups behavior according to, for example, required skills, knowledge, resources, etc., and is performed by a single role within the organization.

Business role A named specific behavior of a business actor participating in a particular context.

Business actor An organizational entity that is capable of performing behavior.

Business process A unit of internal behavior or collection of causally related units of internal behavior intended to produce a defined set of products and services.

Business event Something that happens (internally or externally) and influences behavior.

Business service An externally visible unit of functionality, which is meaningful to the environment and is provided by a business role.

Application Layer

21

Application component

A modular, deployable, and replaceable part of a system that encapsulates its contents and exposes its functionality through a set of interfaces.

Application service An externally visible unit of functionality, provided by one or more components, exposed through well-defined interfaces, and meaningful to the environment.

Application function A coherent group of internal behavior of a component.

Data object A coherent, self-contained piece of information suitable for automated processing.

Technology Layer

Node A computational resource upon which artifacts may be deployed for execution.

Device A physical computational resource upon which artifacts may be deployed for execution.

Network A physical communication medium between two or more devices.

Software system A software environment for specific types of components and objects that are deployed on it in the form of artifacts.

Artifact A physical piece of information that is used or produced in a software development process, or by deployment and operation of a system.

Relations

Flow The flow relationship describes the exchange or transfer of, for example, information or value between processes, function, interactions, and events.

Used by The used by relationship models the use of services by processes, functions, or interactions and the access to interfaces by roles, components, or collaborations.

22

Realization The realization relationship links a logical entity with a more concrete entity that realizes it.

Triggering The triggering relationship describes the temporal or causal relations between processes, functions, interactions, and events.

Access The access relationship models the access of behavioral concepts to business or data objects.

Association Association models a relationship betweenobjects that is not covered by another, more specific relationship.

Grouping relation The grouping relationship indicates that objects, of the same type or different types, belong together based on some common characteristic.