ANLISIS DEL CASO

MEDICINA PREPAGA
ARQUITECTURA DE
APLICACIONES Y
METODOLOGAS DE
EVALUACIN

CONTENIDOS
Introduccin....................................................................................................................... 4
ATAM-1: Presentacion Atam............................................................................................... 5
ATAM-2: Presentacin de Objetivos de Negocio..................................................................6
Principales objetivos de negocio.....................................................................................6
Atributos de calidad........................................................................................................ 6
Stakeholders................................................................................................................... 6
ATAM-3: Presentacin de la arquitectura............................................................................8
Vista fsica...................................................................................................................... 8
Arquitectura actual...................................................................................................... 9
Paso 1: Tercerizar bases de datos no-sensibles para liberar hardware.........................9
Paso 2: Utilizar un servidor libre para agregar una capa de integracin mediante un
producto ESB............................................................................................................. 10
Paso 3: Implementacin de un motor de reglas para deteccin de fraudes...............11
Paso 4: Implementacin de capas de servicio bsicas: Afiliados y Prestaciones........13
Vista Lgica................................................................................................................... 15
ATAM-4: Identificacin de Aproximaciones Arquitectnicas..............................................16
ATAM-5: Generacin de rbol de Utilidad.........................................................................17
ATAM-6: Anlisis de las aproximaciones arquitecturales..................................................18
Escenario S1 - Trazabilidad de todas las operaciones...................................................18
Escenario U1 - Deteccin automtica de fraudes..........................................................19
Escenario E1 - Mejorar el tiempo de salida al mercado con nuevas aplicaciones..........20
Escenario E2 - Incapacidad de seguir adquiriendo y administrando nuevo hardware. . .21
Escenario M1 - El tiempo de implementacin de una modificacin a aplicaciones
existentes no puede ser superior a los 5 das...............................................................22
Escenario R1 - Mantener un tiempo de respuesta en los puntos de atencin inferior a
los 5 minutos................................................................................................................ 23
Escenario D1 - Lograr una respuesta near-online para los sistemas de validacin de
prestaciones en los puntos de atencin........................................................................24
ATAM-7: Brainstorming y priorizacin de escenarios........................................................25

ATAM-8: Anlisis de las aproximaciones arquitecturales..................................................26

ATAM-9: Presentacin de Resultados................................................................................27
Aproximaciones arquitectnicas documentadas...........................................................27
Set de escenarios y su priorizacin...............................................................................27
Riesgos detectados....................................................................................................... 27
No-Riesgos detectados.................................................................................................27
Puntos de Sensibilidad..................................................................................................28
Puntos de Negociacin o Trade-of................................................................................28
ANEXO 1 - Opciones de productos disponibles en el mercado para la arquitectura
propuesta......................................................................................................................... 29
ESB............................................................................................................................... 29
CEP............................................................................................................................... 29
Cloud Computing.......................................................................................................... 29
ANEXO 2 Anlisis Financiero Bsico de la Inversin.......................................................30
Proyeccin a tres aos..................................................................................................30
Grfico del costo mensual total....................................................................................31

INTRODUCCIN
El caso de estudio presentado por la ctedra muestra una organizacin en rpido
crecimiento que necesita un replanteo de su arquitectura de sistemas.
En este trabajo se propone una mejora, que no es la nica posible, pero ayudar a
optimizar los recursos actuales de la organizacin y se alinear con sus objetivos de
negocio para sus planes futuros.
Tomamos como marco de trabajo los temas vistos en clase y utilizamos una metodologa de
evaluacin de arquitecturas (ATAM) para explicar nuestras ideas y detectar/corregir los
riegos en nuestra propuesta.
La metodologa misma incluye una presentacin de los pasos a seguir y cubre todo lo
necesario para exponer nuestro trabajo a los stakeholders, funcionando como va de
comunicacin, documentacin de las decisiones y mtodo de priorizacin de objetivos en
conflicto.
A continuacin comenzamos con ATAM, y finalizamos el trabajo con dos anexos:
ANEXO 1 - Opciones de productos disponibles en el mercado para la arquitectura propuesta
ANEXO 2 - Anlisis financiero bsico de la inversin

ATAM-1: PRESENTACION ATAM

El Architecture Tradeoff Analysis Method (ATAM) es una metodologa para evaluar
Arquitecturas de Software que principalmente evala la adecuacin de la Arquitectura de
Software definida con respecto a los atributos de calidad especificados para el sistema.
El corazn de ATAM consiste en la ejecucin de nueve pasos que se dividen en cuatro
grupos. Esos cuatro grupos en que se dividen los nueve pasos definidos consisten en un
primer grupo de presentacin, donde se intercambia informacin del sistema, un segundo
grupo de investigacin y anlisis, donde se valoran los atributos de calidad claves uno a uno
con las propuestas arquitectnicas, un tercer grupo de pruebas donde se revisan los
resultados obtenidos contra las necesidades relevantes de los stakeholders, y un cuarto y
ltimo grupo donde se presentan los resultados del ATAM.
Lo que se busca es analizar la Arquitectura propuesta a partir de escenarios. Estos
representan una breve interaccin de un stakeholder con el sistema. Se construyen en vista
a los objetivos de negocio (Business Drivers) y a la luz de los atributos de calidad (Quality
Attributes).
El anlisis da como resultado los puntos de sensibilidad, de tradeoff, riesgos y no riesgos.
Este conjunto se procesa y se generan los Risk Themes, que sern los que impactarn en
el plan arquitectnico a desarrollar y en los objetivos de negocio.

ATAM-2: PRESENTACIN DE OBJETIVOS DE NEGOCIO

La arquitectura actual de los sistemas de la empresa claramente presenta un esquema
rgido, el cual dificulta tanto la integracin de sistemas desarrollados con nuevas tecnologas
como la de incorporacin de sistemas legados de nuevas compaas adquiridas.
Otra de las dificultades presentes es la trazabilidad de las operaciones y la deteccin de
fraudes por prestaciones, procesos que se realizan actualmente de forma manual.
Se propone luego un reemplazo de la arquitectura actual que no requiera cambios
estructurales profundos en el datacenter, dada la incapacidad de seguir adquiriendo y
administrando nuevo hardware, pero que sin embargo pueda ofrecer la flexibilidad para
incorporar nuevos sistemas y que permita trazabilidad y deteccin de fraude
parametrizables y completamente automticos.

PRINCIPALES OBJETIVOS DE NEGOCIO

Mantener un tiempo de respuesta en los puntos de atencin inferior a los 5 minutos.

Lograr una respuesta near-online para los sistemas de validacin de prestaciones en los
puntos de atencin.
Reduccin del tiempo de incorporacin tanto de sistemas legados como de sistemas
obtenidos por nuevas adquisiciones.
Reducir el tiempo de implementacin de nuevos desarrollos, tanto correctivos como
evolutivos.
Trazabilidad de todas las operaciones para cumplimentar las normas de la certificacin ISO
2001.
Deteccin automtica de fraudes en prestaciones segn un conjunto de reglas flexible y
fcilmente configurable.
Agilidad en el cambio de sistemas relacionados con la regulacin vigente para adaptarse
rpidamente a las normas y leyes cambiantes del mercado.

ATRIBUTOS DE CALIDAD
Analizando los principales objetivos, se encuentran presentes los siguientes atributos de
calidad:

Rendimiento
Disponibilidad
Escalabilidad
Modificabilidad
Seguridad

STAKEHOLDERS
Los principales stakeholders identificados fueron:

Project Manager
Arquitecto
Lder tcnico de desarrollo
Responsable Infraestructura
Usuarios de los sistemas
Gerencia adquisiciones
Gerencia general

ATAM-3: PRESENTACIN DE LA ARQUITECTURA

VISTA FSICA
La vista fsica de la arquitectura propuesta se muestra a continuacin. Los pasos para llegar
a la misma se detallan en las pginas siguientes.

Diagrama-1: Vista fsica de la arquitectura propuesta

Dada la proyeccin de crecimiento de la empresa, con planes para numerosas

adquisiciones en el mediano plazo, se decidi utilizar un enfoque arquitectnico que facilite
la incorporacin de todo tipo de sistemas de forma simple y gil. Para ello se opt por un
enfoque SOA/EDA a desarrollar de manera gradual.
Como existe una restriccin de negocio asociada a la incapacidad de seguir adquiriendo y
administrando nuevo hardware, se decidi mantener la arquitectura actual de tres capas y
comenzar a trabajar en pequeos cambios que generen un gran impacto.

ARQUITECTURA ACTUAL
Diagrama-2: Vista fsica de la arquitectura actual

PASO 1: TERCERIZAR BASES DE DATOS NO -SENSIBLES PARA LIBERAR

HARDWARE.
Como primer paso, se decidi tercerizar el almacenamiento de algunas bases de datos en
un servicio en la nube de tipo IAAS para poder reestructurar cmodamente el datacenter
para la implementacin de la nueva arquitectura.
Al tratarse de un entorno no controlado, la nube puede representar un aumento del riesgo
de confidencialidad de los datos. Por este motivo se opt por resguardar los datos sensibles

de los clientes dentro de nuestro DataCenter y tercerizar solamente las bases de

Contabilidad y Prestaciones.
Se eligi un servicio de tipo PaaS para delegar la administracin de aquellas bases de datos
en lo que respecta a escalabilidad y performance.
Diagrama-3: Vista fsica de la arquitectura propuesta paso 1.

Como resultado de la tercerizacin, quedan dos servidores libres para continuar con los
cambios.

PASO 2: UTILIZAR UN SERVIDOR LIBRE PARA AGREGAR UNA CAPA DE

INTEGRACIN MEDIANTE UN PRODUCTO ESB.
A continuacin se decidi utilizar una arquitectura de tipo Broker utilizando una Suite ESB.
El producto ser instalado en uno de los servidores liberados en el paso anterior y
proporcionar los adaptadores necesario para los sistemas legados, permitiendo a su vez la
integracin rpida de sistemas nuevos y existentes.

10

Esta capa de integracin permitir un fcil desarrollo en las nuevas tecnologas que estn
marcando una tendencia en el mercado, y proveer mdulos de trazabilidad de las
operaciones para cumplir con los requisitos de la norma ISO 2001 que se quiere adoptar.
Se pueden agregar conexiones al ESB de manera gradual, configurando cada adaptador y
probando cada componente hasta obtener los resultados esperados. En las etapas finales
de la implementacin, el ESB debera estar mediando el acceso a base de datos
compartidas (Afiliados, Prestaciones y Contabilidad).
Diagrama-4: Vista fsica de la arquitectura propuesta paso 2.

PASO 3: IMPLEMENTACIN DE UN MOTOR DE REGLAS PARA DETECCIN

DE FRAUDES.
De esta manera se puede comenzar a implementar sistemas que reaccionen ante los
mensajes o eventos de inters. Estos mensajes se captarn dentro del ESB, y se
direccionarn (Routing) a las aplicaciones nuevas, como ser un motor de reglas para
deteccin de fraudes. Este ltimo ser instalado en el ltimo servidor libre. Se decide no
agregarlo dentro del ESB para poder disponer de las ventajas de un entorno dedicado
(performance, mayor control, menor acoplamiento) y evitar cuellos de botella.
Al tratarse de un producto maduro y parametrizable, permitir el desarrollo rpido de un
sistema flexible que detectar situaciones fraudulentas y notificar en tiempo real a los

11

responsables. De esta manera la organizacin bajar las prdidas por fraudes y comenzar
a recuperar la inversin.

12

Diagrama-5: Vista fsica de la arquitectura propuesta paso 3.

13

Diagrama 6 - Vista del procesamiento de mensajes dentro del ESB

En este punto la organizacin empieza a obtener un beneficio econmico de implementar la

nueva arquitectura. Una vez cubiertos los costos de la nube, se podr continuar la mejora
de la arquitectura implementando servicios de enfoque SOA / EDA.

PASO 4: IMPLEMENTACIN DE CAPAS DE SERVICIO BSICAS: AFILIADOS Y

PRESTACIONES.
Parte de las ganancias se pueden utilizar en la adquisicin de nuevo hardware para las
capas de servicio, ya sea in-house o terceirizado en la nube tipo IaaS.
Se comenzar implementando aquellos servicios ms crticos, como por ejemplo los de
afiliados y prestaciones. La base de Afiliados es accesible desde los cuatro servidores de
aplicaciones (Validacin, Seguros, ART, Atencin), y cada una cuenta con una manera
distinta de accederla, por lo que se dificulta realizar modificaciones y no se cuenta con
control alguno sobre los accesos. Algo similar ocurre con las Prestaciones.
Al implementar una capa de servicios, las dems aplicaciones tendrn menos trabajo por
hacer, y compartirn no solo datos, sino tambin comportamiento. Bajarn los problemas
asociados con la duplicidad de cdigo y las diferentes maneras de acceder a los datos.
La capa de servicios permitir que se desarrollen e integren aplicaciones de manera ms
gil, sencilla, clara, consistente y eficiente.

14

Diagrama-7: Vista fsica de la arquitectura propuesta paso 4.

Dada la necesidad de una disponibilidad elevada de los sistemas involucrados, ser

necesario contar con enlaces que permitan manejar el volumen de datos apropiados para
las transacciones de las bases migradas como tambin de servidores y enlaces
redundantes para poder asegurar una disponibilidad lo ms cercana posible al 100%.

15

VISTA LGICA
De la vista fsica propuesta se desprende la necesidad de contar con una arquitectura que
se adapte al enfoque SOA. Luego, se propone adoptar un modelo por capas, que permita
diferenciar las capas de negocio, acceso a datos y de presentacin y comunicacin.

Diagrama-8: Modelo por capas dentro de las aplicaciones

Como ejemplo se presenta el diagrama de clases del mdulo de Validacin de

Prestaciones, incluyendo la capa de Negocio, DAO y Entidades. Se muestra de esa forma
que las capas de Presentacin y Web Services son fcilmente intercambiables, pudiendo
adoptarse cualquier tecnologa segn la necesidad tecnolgica del momento.
Diagrama-9: Diagrama de clases del mdulo de Prestaciones

16

ATAM-4: IDENTIFICACIN DE APROXIMACIONES

ARQUITECTNICAS
Se identificaron las siguientes aproximaciones:

Enfoque SOA-EDA

Utilizacin de cloud computing para bases de Prestaciones y Contabilidad (PaaS)

Aplicacin de un patrn Broker

Implementacin de un ESB

Implementacin de un motor de reglas CEP-based.

Implementacin de Servicios para Afiliados y Prestaciones.

En los pasos subsiguientes se analizar cada una de ellas y se la pondr a prueba con
escenarios para determinar puntos de sensibilidad, tradeoff, riesgos y no riesgos.

17

ATAM-5: GENERACIN DE RBOL DE UTILIDAD

En este paso, el equipo de evaluacin y los stakeholders identifican y priorizan los atributos
de calidad, conformando lo que se conoce como rbol de Utilidad.
Los rboles de Utilidad ofrecen un mecanismo para traducir objetivos de negocio en
escenarios de calidad.
En el caso estudiado, se detectaron los siguientes atributos de calidad partiendo de los
objetivos de negocio y se pensaron situaciones donde se hagan presentes estos atributos.
ID

Atributo de
calidad

Atributo de calidad (refinado)

Importancia

Dificultad

S1

Seguridad

Trazabilidad de todas las

operaciones

U1

Usabilidad

Deteccin automtica de fraudes

E1

Escalabilidad

Mejorar el tiempo de salida al

mercado con nuevas aplicaciones
y canales que utilicen las
aplicaciones legadas

E2

Escalabilidad

Incapacidad de seguir adquiriendo

y administrando nuevo hardware

R1

Rendimiento

Mantener un tiempo de respuesta

en los puntos de atencin inferior
a los 5 minutos.

D1

Disponibilidad

Lograr una respuesta near-online

para los sistemas de validacin de
prestaciones en los puntos de
atencin.

M1

Modificabilidad

El tiempo de implementacin de
una modificacin a aplicaciones
existentes no puede ser superior a
los 5 das.

A continuacin se detallan los escenarios que surgen a partir del rbol de Utilidad y se
analizan los mismos con respecto a la arquitectura propuesta.

18

ATAM-6: ANLISIS DE LAS APROXIMACIONES ARQUITECTURALES

ESCENARIO S1 - TRAZABILIDAD DE TODAS LAS OPERACIONES

Escenario

S1 - Trazabilidad de todas las operaciones

Atributo

Seguridad

Ambiente

Ejecucin normal

Estimulo

Se realiza cualquier operacin

Respuesta

Se genera un registro con toda la informacin pertinente de la

operacin realizada

Medida de respuesta

El registro se realiza inmediatamente y se lo puede consultar

5 segundos despus de ser efectuada la operacin.

Decisiones arquitecturales

Decision

Riesgo/No
Riesgo

Sensibilidad

Tradeoff

ESB

R1

S1

T1

Servidor
Afiliados

S2

Razonamiento

Un ESB permite centralizar todas las comunicaciones entre

los diferentes componentes de software agregando
funcionalidades extra tales como trazabilidad.
Se toma en cuenta que puede causar overhead y generar
problemas de performance.
Un nuevo sistema de Afiliados permitir desacoplar la base
de datos correspondiente del resto de los sistemas.

Diagrama de arquitectura
relacionado

Ver Diagrama-1 y Diagrama-6

R1: El ESB puede causar overhead y generar problemas de performance.

S1: Modificar la infraestructura existente para que el ESB tenga la suficiente capacidad de
procesamiento exclusiva es vital para evitar problemas de performance.
T1: Pueden darse problemas de Performance cuando el nmero de transacciones
simultneas es elevado. (Tradeoff entre Seguridad y Performance con el ESB)
S2: El nuevo sistema tendr que exponer los servicios necesarios para cumplimentar con
todas las operaciones que se realizan en la arquitectura actual con la base de Afiliados. De
no ser as, y de continuar permitiendo el acceso de las diferentes aplicaciones a la base de
datos de Afiliados, se compromete la integridad de la informacin y se dificulta el control de
la misma.

19

ESCENARIO U1 - DETECCIN AUTOMTICA DE FRAUDES

Escenario

U1 - Deteccin automtica de fraudes

Atributo

Usabilidad

Ambiente

Ejecucin normal

Estimulo

Se realiza cualquier operacin de validacin de prestaciones

o de turnos

Respuesta

Informe automtico sobre si la operacin es o no sospechosa

Medida de respuesta

El informe es totalmente automtico y no demora ms de 10

segundos a partir del momento de la validacin.

Decisiones arquitecturales

Decision

Riesgo/No
Riesgo

Utilizar motor NR1

CEP
NR2
R1

Sensibilidad

Tradeoff

S1
S2

Razonamiento

Existen soluciones ESB que brindan motores de

Procesamiento de Eventos Complejos que permiten la
deteccin de anomalas basados en el anlisis de un
conjunto de eventos ocurridos. Se puede utilizar un motor
dentro del ESB o bien instalar un servidor dedicado. Se opt
por la segunda opcin para reducir el acoplamiento y bajar el
riesgo de tener baja performance en ambos sistemas.

Diagrama de arquitectura
relacionado

Ver Diagrama-1 y Diagrama-6

NR1: Es una implementacin obligada para poder automatizar la deteccin de fraudes

NR2: La deteccin de fraudes se realiza en un proceso asincrnico que no afecta la
performance de las operaciones regulares.
S1: Si el hardware no es suficiente, el motor de reglas puede saturarse, fallar y detenerse.
S2: Ser necesario configurar el motor CEP y mantenerlo actualizado para la deteccin de
fraudes acorde a las legislaciones vigentes.
R1: El CEP puede ser difcil de configurar, prolongando los tiempos de implementacin de
las reglas.

20

ESCENARIO E1 - MEJORAR EL TIEMPO DE SALIDA AL MERCADO CON

NUEVAS APLICACIONES
Escenario

E1 - Mejorar el tiempo de salida al mercado con nuevas

aplicaciones

Atributo

Escalabilidad

Ambiente

Desarrollo

Estimulo

Necesidad de agregar nueva aplicacin tipo ABM simple que

consulte datos existentes, escrita en una tecnologa distinta a
los sistemas que tienen hoy en da implementados.

Respuesta

Aplicacin agregada

Medida de respuesta

La nueva aplicacin no tardar ms de 2 semanas en ser

integrada.

Decisiones arquitecturales

Decision

Riesgo/No
Riesgo

Sensibilidad

ESB

R1

S1

Tradeoff

Razonamiento

Un ESB permite integrar fcil y rpidamente aplicaciones

existentes desarrolladas en diferentes tecnologas sin
necesidad que compartan un protocolo de comunicacin.

Diagrama de arquitectura
relacionado

Ver Diagrama-1

S1: Es necesario contar con el Adapter correspondiente para la aplicacin a agregar, ya sea
comprndolo o desarrollandolo.
R1: Si el Adapter no funciona apropiadamente, la integracin de una aplicacin al ESB
puede fallar en tiempo de runtime.

21

ESCENARIO E2 - INCAPACIDAD DE SEGUIR ADQUIRIENDO Y

ADMINISTRANDO NUEVO HARDWARE
Escenario

E2 - Incapacidad de seguir adquiriendo y administrando

nuevo hardware

Atributo

Escalabilidad

Ambiente

Desarrollo

Estimulo

Necesidad de expandir la infraestructura

Respuesta

Infraestructura expandida

Medida de respuesta

No debe pasar ms de una semana desde que aparece la

necesidad hasta que se dispone de la expansin.

Decisiones arquitecturales

Decision

Riesgo/No
Riesgo

Sensibilidad

Tradeoff

Cloud
computing

R1

S1

T1
T2

Razonamiento

Contratar un servicio de cloud computing bajo la modalidad

Platform Delivery Model para alojar fuera del datacenter las
bases de datos con datos no sensibles ayuda a liberar
espacio fsico para las modificaciones requeridas en la
infraestructura y tambin a utilizar la misma aproximacin
para cualquier requerimiento de crecimiento a futuro.

Diagrama de arquitectura
relacionado

Ver Diagrama-1

S1: Cualquier necesidad de crecimiento se va a ver solucionada con un mnimo esfuerzo,

simplemente contratando un servicio superior.
T1: Al alojar las bases de datos en servidores externos, se requiere contar con enlaces de
alta velocidad para asegurar una performance similar a la obtenida con la infraestructura
vieja y enlaces redundantes para asegurar una disponibilidad cercana al 100% (Tradeoff
entre Costos e Imposibilidad de adquirir y administrar nuevo hardware)
T2: Si bien se contratar un servicio de cloud privado, se asume el riesgo de alojar datos
corporativos en servidores externos a la organizacin. (Tradeoff entre Seguridad e
Imposibilidad de adquirir y administrar nuevo hardware)
R1: Si se caen los enlaces todas las aplicaciones quedarn offline
R2: No se tiene control total sobre los servidores, con lo que se abren nuevas posibilidades
a ataques.

22

ESCENARIO M1 - EL TIEMPO DE IMPLEMENTACIN DE UNA

MODIFICACIN A APLICACIONES EXISTENTES NO PUEDE SER SUPERIOR A
LOS 5 DAS.
Escenario

M1 - El tiempo de implementacin de una modificacin a

aplicaciones existentes no puede ser superior a los 5 das.

Atributo

Modificabilidad

Ambiente

Desarrollo

Estimulo

Cambio a aplicacin existente desarrollado

Respuesta

Cambio implementado

Medida de Respuesta

Tiempo de implementacin igual o inferior a 5 das.

Decisiones arquitecturales

Decision

Riesgo/No
Riesgo

Sensibilidad

ESB

NR1

S1

Tradeoff

Razonamiento

La implementacin de cambios al utilizar un ESB tiene que

ser transparente y tiene que implicar una reduccin del
riesgo de malas implementaciones ya que es posible tener
conviviendo ambas versiones de forma simultnea, de forma
tal que se simplifican las pruebas de implementacin exitosa
en el ambiente operativo como tambin se tiene un
resguardo en caso de requerir un rollback.

Diagrama de arquitectura
relacionado

Ver Diagrama-1

S1: Se requerir contar con una rplica de la configuracin del ruteo de los servicios
modificados en el ESB tanto durante la etapa de implementacin como el periodo de
garanta posterior.
NR1: Se simplifican las pruebas y los procesos de rollback.

23

ESCENARIO R1 - MANTENER UN TIEMPO DE RESPUESTA EN LOS PUNTOS

DE ATENCIN INFERIOR A LOS 5 MINUTOS.
Escenario

R1 - Mantener un tiempo de respuesta en los puntos de atencin

inferior a los 5 minutos.

Atributo

Rendimiento

Ambiente

Ejecucin bajo carga

Estimulo

Punto de atencin realiza alguna operacin.

Respuesta

La operacin es completada en un 10% del tiempo mximo de

atencin.

Medida de Respuesta

El tiempo de respuesta es inferior a los 5 minutos.

Decisiones
arquitecturales

Decision

Riesgo/No
Riesgo

Servidor exclusivo
para el ESB
Tener enlaces de
alta velocidad para
las bases externas
al datacenter

Sensibilidad

Tradeoff

S1
R1

S2

T1

Razonamiento

Siendo el ESB el mdulo central en todas las comunicaciones

entre las diferentes aplicaciones, adems del encargado de
manejar la trazabilidad y deteccin de fraudes, es vital que este
cuente con el poder de procesamiento para llevar a cabo sus
tareas.

Diagrama de
arquitectura relacionado

N/A

S1: Es necesario que el componente central de la nueva arquitectura tenga suficiente poder
de procesamiento tanto como para manejar las transacciones actuales como para manejar
el volumen de transacciones a futuro (teniendo en cuenta las nuevas adquisiciones
planificadas).
S2: Es necesario poder acceder a todos los datos almacenados en servidores tercerizados
con la mayor performance posible.
T1: Los enlaces de alta velocidad implican un alto costo (Tradeoff entre performance y
costo).
R1: Los enlaces pueden fallar, provocando que se pierda acceso a dichas bases de datos.

24

ESCENARIO D1 - LOGRAR UNA RESPUESTA NEAR- ONLINE PARA LOS

SISTEMAS DE VALIDACIN DE PRESTACIONES EN LOS PUNTOS DE
ATENCIN.
Escenario

D1 - Lograr una respuesta near-online para los sistemas de

validacin de prestaciones en los puntos de atencin.

Atributo

Disponibilidad

Ambiente

Ejecucin normal

Estimulo

Se inicia alguna operacin de validacin de prestaciones

Respuesta

La operacin finaliza en tiempo real

Medida de Respuesta

Se considera tiempo real a una respuesta menor a 5

segundos.

Decisiones arquitecturales

Decision

Riesgo/No
Riesgo

Sensibilidad

Tradeoff

Tener enlaces
redundantes
para las bases
externas

R1

S1

T1

Razonamiento

Tener un enlace redundante ayuda a mitigar los riesgos de

prdida de servicio por la cada del enlace principal.

Diagrama de arquitectura
relacionado

N/A

S1: Es necesario poder tener una disponibilidad cercana al 100% de los datos almacenados
en servidores externos.
T1: Los enlaces redundantes implican un incremento del costo (Tradeoff entre Costo y
Disponibilidad).
R1: Los enlaces redundantes tambin pueden fallar.

25

ATAM-7: BRAINSTORMING Y PRIORIZACIN DE ESCENARIOS

Se genero una lista de escenarios posibles y se los priorizo segn su importancia con un
puntaje del 1 al 10 (siendo 1 poco importante y 10 muy importante).
Escenario

Descripcin

Importancia

Se agrega un nuevo sistema

Se cae el enlace principal

Un mismo afiliado intenta validar una prestacin para 2 clnicas 10

en 2 ciudades diferentes

Necesita aumentarse la capacidad de la base de Prestaciones

en un 50%

Se realiza una modificacin en un mdulo crtico

10

Mantener un tiempo de respuesta en los puntos de atencin

inferior a los 5 minutos.

26

ATAM-8: ANLISIS DE LAS APROXIMACIONES ARQUITECTURALES

Se compararon los escenarios del paso 7 con los escenarios del rbol de Utilidad
generados en el paso 5, buscando diferencias en las prioridades y posibles escenarios
nuevos que tengan que agregarse al rbol.
El escenario 1 del paso 7 fue mapeado al escenario E1 del paso 5. Se determin que la
importancia del escenario era menor a la inicialmente planteada, por lo cual se bajo su
importancia en el rbol de Atributos de Alta a Media.
El escenario 5 del paso 7 fue mapeado al escenario M1 del paso 5. Se determin que la
importancia del escenario era mayor a la inicialmente planteada, por lo cual se subi su
importancia en el rbol de Atributos de Media a Alta.

ID

Atributo de
calidad

Atributo de calidad (refinado)

Importancia

Dificultad

S1

Seguridad

Trazabilidad de todas las

operaciones

U1

Usabilidad

Deteccin automtica de fraudes

E1

Escalabilidad

Mejorar el tiempo de salida al

mercado con nuevas aplicaciones
y canales que utilicen las
aplicaciones legadas

E2

Escalabilidad

Incapacidad de seguir adquiriendo

y administrando nuevo hardware

R1

Rendimiento

Mantener un tiempo de respuesta

en los puntos de atencin inferior
a los 5 minutos.

D1

Disponibilidad

Lograr una respuesta near-online

para los sistemas de validacin de
prestaciones en los puntos de
atencin.

M1

Modificabilidad

El tiempo de implementacin de
una modificacin a aplicaciones
existentes no puede ser superior a
los 5 das.

27

ATAM-9: PRESENTACIN DE RESULTADOS

Como ltimo paso se presentan los resultados obtenidos de la evaluacin

APROXIMACIONES ARQUITECTNICAS DOCUMENTADAS

El presente documento conforma la documentacin necesaria para entender las decisiones
arquitectnicas en el punto de Descripcin de la Arquitectura.

SET DE ESCENARIOS Y SU PRIORIZACIN

Ordenados de ms importantes a menos importantes (Prioridad descendente), los
escenarios utilizados en la evaluacin se listan a continuacin.:
Escenario S1 - Trazabilidad de todas las operaciones
Escenario U1 - Deteccin automtica de fraudes
Escenario E2 - Incapacidad de seguir adquiriendo y adm. nuevo hardware
Escenario M1 - El tiempo de imp. de una modificacin debe ser menor a 5 das.
Escenario R1 - Tiempo de respuesta en puntos de atencin inferior a 5 minutos.
Escenario E1 - Mejorar el tiempo de salida al mercado con nuevas aplicaciones
Escenario D1 - Respuesta near-online para sist. de validacin prestaciones.

RIESGOS DETECTADOS

El ESB puede causar overhead y generar problemas de performance.

El CEP puede ser difcil de configurar, prolongando los tiempos de implementacin de las
reglas.
ESB: Si los Adapters no funcionan apropiadamente, la integracin de una aplicacin al ESB
puede demorarse o fallar en tiempo de runtime.

NO-RIESGOS DETECTADOS

El motor de reglas una implementacin obligada para poder automatizar la deteccin de

fraudes
La deteccin de fraudes se realiza en un proceso asincrnico que no afecta la performance
de las operaciones regulares.
Si el hardware no es suficiente, el motor de reglas puede saturarse, fallar y detenerse.
Ser necesario configurar el motor CEP y mantenerlo actualizado para la deteccin de
fraudes acorde a las legislaciones vigentes.

PUNTOS DE SENSIBILIDAD

28

Modificar la infraestructura existente para que el ESB tenga la suficiente capacidad de

procesamiento exclusiva es vital para evitar problemas de performance.
SOA: El nuevo sistema tendr que exponer los servicios necesarios para cumplimentar con
todas las operaciones que se realizan en la arquitectura actual. De no ser as, y de
continuar permitiendo el acceso directo de las diferentes aplicaciones a las bases de datos,
se compromete la integridad de la informacin y se dificulta el control de la misma, se
duplica cdigo y se confunde el comportamiento de las entidades.
ESB: Es necesario contar con el Adapter correspondiente para la aplicacin a agregar, ya
sea comprndolo o desarrollandolo.
ESB: Se requerir contar con una rplica de la configuracin del ruteo de los servicios
modificados tanto durante la etapa de implementacin como el periodo de garanta
posterior.

PUNTOS DE NEGOCIACIN O TRADE-OFF

ESB con trazabilidad activada: Pueden darse problemas de Performance cuando el nmero
de transacciones simultneas es elevado. (Tradeoff entre Seguridad y Performance con el
ESB)
Al alojar las bases de datos en servidores externos, se requiere contar con enlaces de alta
velocidad para asegurar una performance similar a la obtenida con la infraestructura vieja y
enlaces redundantes para asegurar una disponibilidad cercana al 100% (Tradeoff entre
Costos e Imposibilidad de adquirir y administrar nuevo hardware)
Si bien se contratar un servicio de cloud privado, se asume el riesgo de alojar datos
corporativos en servidores externos a la organizacin. (Tradeoff entre Seguridad e
Imposibilidad de adquirir y administrar nuevo hardware)
Los enlaces redundantes implican un incremento del costo (Tradeoff entre Costo y
Disponibilidad).
Los enlaces de alta velocidad implican un alto costo (Tradeoff entre performance y costo).

29

ANEXO 1 - OPCIONES DE PRODUCTOS DISPONIBLES EN EL

MERCADO PARA LA ARQUITECTURA PROPUESTA
En este anexo se presentan diferentes alternativas de productos y servicios para llevar a
cabo los cambios propuestos por la arquitectura.

ESB

muleESB es una solucin open-source desarrollada en Java, muy liviana y altamente

escalable. Su costo es proporcional a la complejidad del proyecto, pero se estima mucho
menor que similares productos comerciales cerrados.
Adems, cuenta con una versin gratuita con la que es posible conformar un ambiente de
pruebas para verificar si el producto se ajusta a las necesidades de la organizacin.
http://www.mulesoft.com/

CEP

Esper es un componente de procesamiento de eventos complejos desarrollado en Java,

recomendado por Mule Soft para ser integrado con muleESB.
http://www.espertech.com/products/esper.php

CLOUD COMPUTING

Rackspace es una empresa que ofrece todo tipo de servicios en la nube, desde SaaS hasta
IaaS. En el caso particular de nuestra necesidad, la empresa ofrece un servicio de hosting
de base de datos, ofreciendo un servicio de nube privada que garantiza el maximo poder
computacional
http://www.rackspace.com/

30

ANEXO 2 ANLISIS FINANCIERO BSICO DE LA INVERSIN

En este anexo se presentan un anlisis financiero bsico que representa las decisiones
arquitectnicas que impactan en el presupuesto de la empresa.

PROYECCIN A TRES AOS

Consideramos que las prdidas por fraudes ascienden a $150000 pesos mensuales, con
variaciones de un 4% mes a mes. Estimamos que con el CEP se podr bajar esa cifra en un
90% aproximadamente.
Perdidas
por
fraudes ($)

Costo mensual
de
tercerizacion
($)

Costo
total ($)

Enero 2013

161564

161564

Febrero 2013

162574

162574

Marzo 2013

163652

163652

Abril 2013

163548

163548

Mayo 2013

161685

161685

Junio 2013

162358

5500

167858

Julio 2013

163652

10600

174252

Agosto 2013
Septiembre
2013

163048

10600

173648

162685

10600

173285

Octubre 2013

162358

10600

172958

Noviembre 2013

163698

10600

174298

Diciembre 2013

153581

10600

164181

Implementacin CEP

Enero 2014

123215

10600

133815

Agregado de reglas al CEP

Febrero 2014

102054

10600

112654

Agregado de reglas al CEP

Marzo 2014

75158

10600

85758

Agregado de reglas al CEP

Abril 2014

51685

10600

62285

Agregado de reglas al CEP

Mayo 2014

42054

10600

52654

Agregado de reglas al CEP

Junio 2014

38128

10600

48728

Agregado de reglas al CEP

Julio 2014

25090

10600

35690

Agosto 2014
Septiembre
2014

21850

17800

39650

18350

17800

36150

Octubre 2014

17025

25400

42425

Noviembre 2014

16128

25400

41528

Diciembre 2014

15450

25400

40850

Enero 2015

15128

25400

40528

Febrero 2015

15025

25400

40425

Marzo 2015

15230

25400

40630

Abril 2015

15180

25400

40580

Mes

Decisiones
arquitectnicas

Tercerizacin de BD
Contabilidad
Tercerizacin de BD
Prestaciones

Tercerizacin de Servicios

Mejora de Enlaces

31

Mayo 2015

15295

25400

40695

Junio 2015

15368

25400

40768

Julio 2015

15286

25400

40686

Agosto 2015
Septiembre
2015

15485

25400

40885

15368

25400

40768

Octubre 2015

15398

25400

40798

Noviembre 2015

15450

25400

40850

Diciembre 2015

15350

25400

40750

GRFICO DEL COSTO MENSUAL TOTAL

200000
180000
160000
140000
120000
100000
80000
Perdidas por fraudes ($)
60000

Costo mensual de tercerizacion ($)

Costo total ($)

40000
20000
0

La lnea azul representa las prdidas por fraudes mensuales. Se observa que luego de la
implementacin del CEP, el monto disminuye hasta volver a estabilizarse a un 10% del
monto original (el sistema no puede detectar todos los fraudes).
La lnea roja representa el costo adicional de tercerizacin de equipos en la nube. Se
comienza tercerizando dos servidores en Mayo de 2013, y en Julio de 2014 se realiza la
segunda migracin a servidores de servicios. Casi al mismo tiempo, se mejoran los enlaces
(aumento de disponibilidad).
La lnea verde muestra el costo total que representa para la empresa la arquitectura de
sistemas. A pesar de aumentar el gasto en la tercerizacin, los ahorros obtenidos por el
motor de reglas de fraude son mayores, y se traducen en un ahorro de un 75%, de $160000

32

a $40000. (No se incluyen en el anlisis los dems beneficios obtenidos ni el gasto

generado por el equipo de sistemas.)
Con este reporte finalizamos el estudio, y recomendamos el cambio de arquitectura a
implementarse lo antes posible, para comenzar a reducir costos en la organizacin.

33