1

Ingeniera de Sistemas y Computacin

ISIS-2403 Arquitectura Empresarial y de Solucin
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.
2


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


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.
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 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.
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 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:
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 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.
10


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.

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 ArchiSurances IT is that the IT integration should be
invisible to ArchiSurances 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 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:
13


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


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:
15


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

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


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.
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 notacin
Concepto Descripcin Notacin
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.