ARQUITECTURA APLICACIONES

TP ARQ. APLIC.docx

Anlisis del casoMedicina Prepaga

Arquitectura de Aplicaciones y Metodologas de Evaluacin

ContenIDOSIntroduccin4ATAM-1: Presentacion Atam5ATAM-2: Presentacin de Objetivos de Negocio6Principales objetivos de negocio6Atributos de calidad6Stakeholders6ATAM-3: Presentacin de la arquitectura8Vista fsica8Arquitectura actual9Paso 1: Tercerizar bases de datos no-sensibles para liberar hardware.9Paso 2: Utilizar un servidor libre para agregar una capa de integracin mediante un producto ESB.10Paso 3: Implementacin de un motor de reglas para deteccin de fraudes.11Paso 4: Implementacin de capas de servicio bsicas: Afiliados y Prestaciones.13Vista Lgica15ATAM-4: Identificacin de Aproximaciones Arquitectnicas16ATAM-5: Generacin de rbol de Utilidad17ATAM-6: Anlisis de las aproximaciones arquitecturales18Escenario S1 - Trazabilidad de todas las operaciones18Escenario U1 - Deteccin automtica de fraudes19Escenario E1 - Mejorar el tiempo de salida al mercado con nuevas aplicaciones20Escenario E2 - Incapacidad de seguir adquiriendo y administrando nuevo hardware21Escenario M1 - El tiempo de implementacin de una modificacin a aplicaciones existentes no puede ser superior a los 5 das.22Escenario R1 - Mantener un tiempo de respuesta en los puntos de atencin inferior a los 5 minutos.23Escenario D1 - Lograr una respuesta near-online para los sistemas de validacin de prestaciones en los puntos de atencin.24ATAM-7: Brainstorming y priorizacin de escenarios25ATAM-8: Anlisis de las aproximaciones arquitecturales26ATAM-9: Presentacin de Resultados27Aproximaciones arquitectnicas documentadas27Set de escenarios y su priorizacin27Riesgos detectados27No-Riesgos detectados27Puntos de Sensibilidad28Puntos de Negociacin o Trade-off28ANEXO 1 - Opciones de productos disponibles en el mercado para la arquitectura propuesta29ESB29CEP29Cloud Computing29ANEXO 2 Anlisis Financiero Bsico de la Inversin30Proyeccin a tres aos30Grfico del costo mensual total31

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

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 responsables. De esta manera la organizacin bajar las prdidas por fraudes y comenzar a recuperar la inversin.


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.


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

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

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.

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.

IDAtributo de calidadAtributo de calidad (refinado)ImportanciaDificultad

S1SeguridadTrazabilidad de todas las operacionesAB

U1UsabilidadDeteccin automtica de fraudesAM

E1EscalabilidadMejorar el tiempo de salida al mercado con nuevas aplicaciones y canales que utilicen las aplicaciones legadasAM

E2EscalabilidadIncapacidad de seguir adquiriendo y administrando nuevo hardwareAB

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

D1DisponibilidadLograr una respuesta near-online para los sistemas de validacin de prestaciones en los puntos de atencin.MM

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

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.

ATAM-6: Anlisis de las aproximaciones arquitecturales

Escenario S1 - Trazabilidad de todas las operaciones

EscenarioS1 - Trazabilidad de todas las operaciones

AtributoSeguridad

AmbienteEjecucin normal

EstimuloSe realiza cualquier operacin

RespuestaSe genera un registro con toda la informacin pertinente de la operacin realizada

Medida de respuestaEl registro se realiza inmediatamente y se lo puede consultar 5 segundos despus de ser efectuada la operacin.

Decisiones arquitecturalesDecisionRiesgo/No RiesgoSensibilidadTradeoff

ESBR1S1T1

Servidor AfiliadosS2

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

Escenario U1 - Deteccin automtica de fraudes

EscenarioU1 - Deteccin automtica de fraudes

AtributoUsabilidad


EstimuloSe realiza cualquier operacin de validacin de prestaciones o de turnos

RespuestaInforme automtico sobre si la operacin es o no sospechosa

Medida de respuestaEl informe es totalmente automtico y no demora ms de 10 segundos a partir del momento de la validacin.


Utilizar motor CEPNR1NR2R1S1S2

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

Escenario E1 - Mejorar el tiempo de salida al mercado con nuevas aplicaciones

EscenarioE1 - Mejorar el tiempo de salida al mercado con nuevas aplicaciones

AtributoEscalabilidad

AmbienteDesarrollo

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

RespuestaAplicacin agregada

Medida de respuestaLa nueva aplicacin no tardar ms de 2 semanas en ser integrada.


ESBR1S1

RazonamientoUn ESB permite integrar fcil y rpidamente aplicaciones existentes desarrolladas en diferentes tecnologas sin necesidad que compartan un protocolo de comunicacin.

Diagrama de arquitectura relacionadoVer 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.

Escenario E2 - Incapacidad de seguir adquiriendo y administrando nuevo hardware

EscenarioE2 - Incapacidad de seguir adquiriendo y administrando nuevo hardware

AtributoEscalabilidad

AmbienteDesarrollo

EstimuloNecesidad de expandir la infraestructura

RespuestaInfraestructura expandida

Medida de respuestaNo debe pasar ms de una semana desde que aparece la necesidad hasta que se dispone de la expansin.


Cloud computingR1S1T1T2

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


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.

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

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

AtributoModificabilidad

AmbienteDesarrollo

EstimuloCambio a aplicacin existente desarrollado

RespuestaCambio implementado

Medida de RespuestaTiempo de implementacin igual o inferior a 5 das.


ESBNR1S1

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


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.

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

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

AtributoRendimiento

AmbienteEjecucin bajo carga

EstimuloPunto de atencin realiza alguna operacin.

RespuestaLa operacin es completada en un 10% del tiempo mximo de atencin.

Medida de RespuestaEl tiempo de respuesta es inferior a los 5 minutos.


Servidor exclusivo para el ESBS1

Tener enlaces de alta velocidad para las bases externas al datacenterR1S2T1

RazonamientoSiendo 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 relacionadoN/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.

Escenario D1 - Lograr una respuesta near-online para los sistemas de validacin de prestaciones en los puntos de atencin.

EscenarioD1 - Lograr una respuesta near-online para los sistemas de validacin de prestaciones en los puntos de atencin.

AtributoDisponibilidad


EstimuloSe inicia alguna operacin de validacin de prestaciones

RespuestaLa operacin finaliza en tiempo real

Medida de RespuestaSe considera tiempo real a una respuesta menor a 5 segundos.


Tener enlaces redundantes para las bases externasR1S1T1

RazonamientoTener un enlace redundante ayuda a mitigar los riesgos de prdida de servicio por la cada del enlace principal.

Diagrama de arquitectura relacionadoN/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.

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

EscenarioDescripcinImportancia

1Se agrega un nuevo sistema7

2Se cae el enlace principal8

3Un mismo afiliado intenta validar una prestacin para 2 clnicas en 2 ciudades diferentes10

4Necesita aumentarse la capacidad de la base de Prestaciones en un 50%4

5Se realiza una modificacin en un mdulo crtico10

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

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.

IDAtributo de calidadAtributo de calidad (refinado)ImportanciaDificultad

S1SeguridadTrazabilidad de todas las operacionesAB

U1UsabilidadDeteccin automtica de fraudesAM

E1EscalabilidadMejorar el tiempo de salida al mercado con nuevas aplicaciones y canales que utilicen las aplicaciones legadasMM

E2EscalabilidadIncapacidad de seguir adquiriendo y administrando nuevo hardwareAB

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

D1DisponibilidadLograr una respuesta near-online para los sistemas de validacin de prestaciones en los puntos de atencin.MM

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

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 operacionesEscenario U1 - Deteccin automtica de fraudesEscenario E2 - Incapacidad de seguir adquiriendo y adm. nuevo hardwareEscenario 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 aplicacionesEscenario 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

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

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/

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.

MesPerdidas por fraudes ($)Costo mensual de tercerizacion ($)Costo total ($)Decisiones arquitectnicas

Enero 20131615640161564

Febrero 20131625740162574

Marzo 20131636520163652

Abril 20131635480163548

Mayo 20131616850161685

Junio 20131623585500167858Tercerizacin de BD Contabilidad

Julio 201316365210600174252Tercerizacin de BD Prestaciones

Agosto 201316304810600173648

Septiembre 201316268510600173285

Octubre 201316235810600172958

Noviembre 201316369810600174298

Diciembre 201315358110600164181Implementacin CEP

Enero 201412321510600133815Agregado de reglas al CEP

Febrero 201410205410600112654Agregado de reglas al CEP

Marzo 2014751581060085758Agregado de reglas al CEP

Abril 2014516851060062285Agregado de reglas al CEP

Mayo 2014420541060052654Agregado de reglas al CEP

Junio 2014381281060048728Agregado de reglas al CEP

Julio 2014250901060035690

Agosto 2014218501780039650Tercerizacin de Servicios

Septiembre 2014183501780036150

Octubre 2014170252540042425Mejora de Enlaces

Noviembre 2014161282540041528

Diciembre 2014154502540040850

Enero 2015151282540040528

Febrero 2015150252540040425

Marzo 2015152302540040630

Abril 2015151802540040580

Mayo 2015152952540040695

Junio 2015153682540040768

Julio 2015152862540040686

Agosto 2015154852540040885

Septiembre 2015153682540040768

Octubre 2015153982540040798

Noviembre 2015154502540040850

Diciembre 2015153502540040750

Grfico del costo mensual total

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

ARQUITECTURA APLICACIONES

Documents

Transcript of ARQUITECTURA APLICACIONES