ISIS-2403 Arquitectura Empresarial y de Solucin

Ingeniera de Sistemas y Computacin 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 desarrollarn 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 relacin entre aplicaciones lgicas y artefactos fsicos

Al final del documento se puede encontrar un resumen de todos los elementos utilizados en este tutorial. Para obtener la especificacin de todos los elementos de Archimate, referirse a la especificacin 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 ArchiSurances 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 agrupacin de funciones.

Ahora creamos las funciones dentro de la agrupacin ingresando en New multiple > Business function.

Cada funcin que se define puede tener atributos. En este caso vamos a adicionar el atributo de documentacin para ingresar informacin acerca de la funcin.

Se ingresan los nombres e informacin 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 agrupacin de actores primero ingresando en New > Business actors.

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

Ingresamos los nombres y descripciones de los roles.

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. 5

Organizar los elementos de manera que tenga la siguiente disposicin:

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

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 7

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 organizacin se modela con el Organization Viewpoint. Este punto de vista modela la estructura interna de la organizacin, relacionando actores, roles, interfaces y colaboraciones de negocio. En primera instancia debemos crear los actores. Dentro de la agrupacin 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:

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 agrupacin 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.

Existe un elemento de relacin que se llama Grouping el cual se usa para agrupar otros elementos con caractersticas similares. Vamos a utilizar este elemento para agrupar las aplicaciones.

10

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 ArchiSurances IT is that the IT integration should be invisible to ArchiSurances clients: products & services remain the same. However, this is not a 11

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 cooperacin 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 travs 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:

12

A continuacin 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 relacin de realizacin indica que el proceso es realizado por el servicio, la relacin de trigger indica que ese evento o proceso arranca el siguiente, y la relacin 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 aplicacin; y data objects. Para este punto de vista vamos a crear servicios de aplicacin. Para ello, dentro del grupo de aplicaciones, seleccionamos New multiple > Application service.

13

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

A continuacin 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:

14

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

Debemos crear un servicio de aplicacin Policy creation service y los data objects Insurance request, Insurance policy y Customer file. Para la creacin de los data objects es necesario crear primero un grupo de tipo Application data que tendr el mismo nombre.

15

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

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

16

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 lgicas y artefactos fsicos. El punto de vista de infraestructura modela servicios e interfaces de infraestructura, artefactos, rutas de comunicacin, 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.

17

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

Para finalizar, desarrollaremos el diagrama de relacin de aspectos lgicos y fsicos. 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.

18

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.

19

Resumen de notacin
Concepto 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. A named specific behavior of a business actor participating in a particular context. Descripcin Notacin

Business role

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. Something that happens (internally or externally) and influences behavior.

Business event

Business service

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

Application Layer

20

Application component

A modular, deployable, and replaceable part of a system that encapsulates its contents and exposes its functionality through a set of interfaces. An externally visible unit of functionality, provided by one or more components, exposed through well-defined interfaces, and meaningful to the environment. A coherent group of internal behavior of a component.

Application service

Application function

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. The used by relationship models the use of services by processes, functions, or interactions and the access to interfaces by roles, components, or collaborations.

Used by

21

Realization

The realization relationship links a logical entity with a more concrete entity that realizes it. The triggering relationship describes the temporal or causal relations between processes, functions, interactions, and events. The access relationship models the access of behavioral concepts to business or data objects.

Triggering

Access

Association

Association models a relationship betweenobjects that is not covered by another, more specific relationship. The grouping relationship indicates that objects, of the same type or different types, belong together based on some common characteristic.

Grouping relation

22