Taller 3. Arquitectura de Solución SOA

Taller 3. Arquitectura de
Solución SOA
2010
Andrés González. 201018063
Especialización en construcción de software
Universidad de los andes
Bogotá 2010
Julián Morales. 200213074
Carlos Criales. 200925612
José Daniel García. 200818257
Robinson De La Hoz. 201018033
Haiver Páez. 201018119
Versión
Modificado por
Descripción
Fecha
1
Grupo de Trabajo .jarc
Creación del documento de arquitectura de datos
Mayo 11 de 2010
1.1
Grupo de Trabajo .jarc
Inclusión de correcciones
Mayo 18 de 2010
1.2
Grupo de Trabajo .jarc
Inclusión de vistas
Mayo 18 de 2010
CONTENIDO
1.
Introducción
6
2.
Objetivos
7
3.
Supuestos
8
4.
Abstracción y análisis de la arquitectura de solución a través de puntos de vista 9
4.1 Componentes .............................................................................................................................. 9
4.2
4.3
5.
Zonas ................................................................................................................................ 10
4.2.1
Canales ................................................................................................................. 10
4.2.2
Conectores ............................................................................................................ 11
4.2.3
Middleware (integración) ..................................................................................... 11
4.2.4
Aplicaciones ......................................................................................................... 11
4.2.5
Almacenamiento (BDs) ........................................................................................ 12
4.2.6
Sistemas de Archivos ........................................................................................... 12
Vistas ................................................................................................................................ 13
4.3.1
Proveedores Externos ........................................................................................... 14
4.3.2
Plataforma ............................................................................................................ 16
4.3.3
Seguridad ............................................................................................................. 17
4.3.4
Persistencia ........................................................................................................... 18
PORTAFOLIO DE SERVICIOS
19
5.1
5.2
5.3
6
identificación de servicios ................................................................................................ 19
5.1.1
enfoque top-down ................................................................................................. 19
5.1.2
enfoque BOTTOM- UP ........................................................................................ 19
5.1.3
enfoque de arquitectura ........................................................................................ 20
categorizacion de servicios por taxonomia ....................................................................... 21
5.2.1
SERVICIOS DE ENTIDAD ................................................................................ 21
5.2.2
SERVICIOS DE funcionalidad ............................................................................ 21
5.2.3
SERVICIOS DE INFRAESTRUCTURA ............................................................ 22
5.2.4
SERVICIOS DE sistema de informacion ............................................................. 22
5.2.5
SERVICIOS DE PROCESOS DE NEGOCIO ..................................................... 22
contratos de los servicios .................................................................................................. 23
arquitectura de solución bajo el estilo de arquitectura SOA
24
6.1
BLUEPRINT DE ARQUITECTURA NIVEL 1 .............................................................. 24
6.2
Documentación ZONAS................................................................................................... 25
6.2.6
6.2.1
ZONA DE CANALES ......................................................................................... 25
6.1.1
ZONA DE PROCESOS ....................................................................................... 26
6.1.2
ZONA DE Servicios............................................................................................. 26
6.1.3
ZONA DE PROVEEDORES ............................................................................... 27
6.1.4
ZONA DE DATOS .............................................................................................. 28
DIALECTO DE DATOS CANONICO ............................................................................ 28
6.3
BLUEPRINT DE ARQUITECTURA NIVEL 2 .............................................................. 30
6.4
Documentación DE SERVICIOS Y ADAPTADORES (RNF) ........................................ 31
6.4.1
Servicios No Funcionales ..................................................................................... 32
6.4.2
Servicios Tipo Adaptador (ABCS) ....................................................................... 32
6.4.3
Soporte de los requerimientos no Funcionales ..................................................... 33
7
Lecciones Aprendidas
38
8.
Conclusiones
39
9.
Bibliografía
40
1. INTRODUCCIÓN
En una empresa típica, muchas arquitecturas van a existir en un punto del tiempo, algunas cubren necesidades específicas, otras son más generales, algunas
agregan detalle. Como sea, habrán muchas soluciones en uso o siendo consideradas para usar en orden se satisfacer las necesidades de la empresa. Cada una
de esas soluciones no trabaja independiente, por el contrario, trabajan en conjunto y para poderlas entender, se hace necesario definir clasificaciones para las
arquitecturas, definiendo vistas, fronteras y relaciones en orden de simplificar el la administración de la empresa.
Este documento tiene como finalidad mostrar el detalle de la solución planteada por el equipo de trabajo para el problema presentado en el banco los Alpes.
Siendo esta la tercera entrega, se llega a un nivel detallado de la solución teniendo en cuenta todos los aspectos técnicos, metodologías vistas en clase y
complementando de las entregas anteriores.
2. OBJETIVOS
El presente trabajo tiene como objetivo mostrar el análisis y la documentación de la arquitectura solución a través de los puntos de vista, la definición del
portafolio de servicios requeridos para soportar la automatización de los procesos de negocio de la generación de crédito a través de los enfoques vistos en
clase y el desarrollo de la arquitectura solución bajo el estilo SOA.
Dentro de los objetivos específicos propuestos para el presente trabajo se encuentran los siguientes:






Identificar los diferentes puntos de vista que se utilizaran para definir la arquitectura solución
Identificar los elementos y las relaciones que existen en cada vista
Identificar los servicios que van a ser empleados por la arquitectura solución, partiendo de varios enfoques tales como BOTTOM UP, TOP DOWN,
etc.
Categorizar los servicios identificados de acuerdo a varias taxonomías
Elaborar los contratos respectivos de cada servicio que permitan tener una visión exacta de la utilidad y comportamiento del servicio
Desarrollar los blueprint de arquitectura, en donde se pueda apreciar claramente las zonas, los servicios, los requerimientos no funcionales y sus
interrelaciones a través de canales de comunicación y mensajes.
3. SUPUESTOS
o
o
o
No existen soluciones adicionales o complementarias a las presentadas en el enunciado general del proyecto, es decir, solamente se consideraron las
aplicaciones indicadas en ese documento.
Suponemos que no se tiene detalle de los canales, estructura de mensajes y datos que son utilizados por los proveedores de servicios
Suponemos que no debemos desarrollar los siguientes servicios, dado que el banco ya tiene implementadas tales funcionalidades



Sincronización de tiempos entre los sistemas
Grabaciones de las llamadas al servicio automático de audio respuesta
Servidor de Correo
4. ABSTRACCIÓN Y ANÁLISIS DE LA ARQUITECTURA DE SOLUCIÓN A TRAVÉS DE PUNTOS DE VISTA
4.1 COMPONENTES














IVR: Consiste en un sistema telefónico que es capaz de recibir una llamada e interactuar con el humano a través de grabaciones de voz y el
reconocimiento de respuestas simples, como "sí", "no" u otras. Es un sistema automatizado de respuesta interactiva, orientado a entregar y/o capturar
información a través del teléfono, permitiendo el acceso a servicios de información u otras operaciones.
Portal: Sitio Web del Banco de los Alpes que permite a los clientes acceder a información de los productos y servicios que el banco ofrece, del mismo
modo, le permite al “cuenta-habiente” realizar diferentes acciones como: activar, editar y bloquear productos; actualización de información personal,
acceder a servicios.
ATM (Automated Teller Machine): Cajero automático, permite la realización de diferentes transacciones dependiendo de los servicios que ofrezca la
entidad bancaria, para el Banco de Los Alpes, aplican, transacciones con la cuenta de ahorros y transacciones con la tarjeta de crédito (retiro de
dinero, ingreso de dinero, avances en tarjeta de crédito).
SMS (Short Message Service): Servicio disponible en dispositivos celulares que permite el intercambio de mensajes compuestos por texto no mayores a
160 caracteres. Estos mensajes, favorecerían la rapidez con la que el banco se comunicará con los clientes con el fin de ofrecer nuevos productos e
informar a cerca de actividades realizadas con los productos que ya ha adquirido.
ESB (Enterprise Service Bus): “Combinado de arquitectura de software que proporciona servicios fundamentales para arquitecturas complejas a través
de sistemas de mensajes”. Es decir es una herramienta que va a permitir que las diferentes aplicaciones que utilizan diferentes protocolos de
comunicación y tipos de datos, se integren.
Credit Card System: Cargar archivos planos de los proveedores de clientes prospectos.
Savings Systems: Gestionar la información de cuentas de ahorro
Loans Credit System: Gestionar la información de créditos de libre inversión
Broadcast System: Contactar al cliente vía telefónica y por correo electrónico
Mail Server: Prestar el servicio de envío de correo electrónico
Dashboard: Desplegar indicadores y eventos que serán monitoreados
Making Financial Group System: Generar plásticos de tarjetas crédito y debito
Partner File Loader System: Cargar archivos planos de los proveedores de clientes prospectos.
Customer Scoring Systems: Depurar y segmentar los clientes prospectos







CRM: Registrar los prospectos que pasan los filtros del área de riesgo
Enviar vía Sockets los clientes a los que se les pre aprobó tarjeta de crédito, registrar la información de clientes a los que se les pre aprobó crédito de
libre inversión, enviar vía Sockets la información de los clientes a los que se les solicitará información adicional, enviar información de clientes para
realce de tarjetas, activar productos a través de Call center, multicanales(Portal, IVR, ATM, Redes Sociales) e inactivar los registros de clientes que
rechazan productos.
Credit Card Integrated System: Gestionar la información de tarjetas de crédito
OLAP (On Line Analytical Processing): Dentro de las bases de datos debemos tener una base de datos que permita realizar inteligencia de negocio y
verificación de los diferentes KPIs a implementar.
OLTP (On Line Transaction Processing): Base de datos transaccional que permita el almacenamiento de información, con los procesos que se llevan a
cabo en el banco.
ETL: Aunque el ETL no es ninguna aplicación, podemos decir que es un mecanismo que nos permite ingresar y validar todos los registros enviados por
agencias externas.
Medios de comunicación
SOAP/Web Services (Simple Object Access Protocol): Protocolo que permite a través de http envio y recepción de información por medio de llamados
de procedimientos (funciones métodos). Para nuestro caso de estudio es usado por alrededor del 60% de las diferentes aplicaciones.
JMS (Java Message Service): Permite la recepción, envío, creación y lectura de mensajes, de manera síncrona o asíncrona.
4.2 ZONAS
4.2.1 CANALES
Descripción: En esta zona se encuentran los canales IVR, Portal, ATM(Cajeros) y SMS. Además permite el acceso los diversos puntos de acceso a los
sistemas del banco.
Objetivo: Agrupar los diversos puntos de acceso a los sistemas del banco.
Responsabilidades: Autorizar, denegar el acceso a la información y comunicarse con los sistemas internos del banco. Categorizar por tipos de acceso a
los clientes del as aplicaciones del banco.
4.2.2 CONECTORES
Descripción: Dentro de esta zona transformaremos la información proveniente de la zona de los canales con el fin de dejar todos y cada uno de los
mensajes de manera que todos los sistemas de información del banco entiendan claramente
Objetivo: Transformar y/o dar formato a los mensajes.
Responsabilidades: Transformar, completar los mensajes, con el fin de dejar la información en un formato en el cual el “middleware” pueda entender.
4.2.3 MIDDLEWARE (INTEGRACIÓN)
Descripción: Zona encargada de enrutar los mensajes a las diferentes aplicaciones. Del mismo modo permite integrar las diferentes aplicaciones a
través de un ESB, para dichos llamados se emplearán (Sockets, SOAP/Webservices, JMS)
Objetivo: Enrutar los mensajes provenientes de los diferentes canales a las aplicaciones correspondientes. Integrar los diferentes procesos del Banco
de los Alpes.
Responsabilidades: Recibir los mensajes en un lenguaje estándar (XML) y redireccionar dichos mensajes a las aplicaciones correspondientes. Tener
control del flujo de la información dentro de las diferentes aplicaciones del Banco de Los Alpes.
4.2.4 APLICACIONES
Descripción: Zona encargada del manejo específico a cada uno de los mensajes enviados por la Zona de Middleware, es aquí donde dichos mensajes
son manejados para cumplir con las reglas de negocio. Dentro de estas aplicaciones podemos ver: Credit Card System, Savings Systems, Loans Credit
System, Broadcast System, Mail Server, Dashboard, Making Financial Group System, Parner FileLoader System, Customer Scoring System, CRM, Credit
Card Integrated System.
Objetivo: Implementación de requerimientos
Responsabilidades: Recibir mensajes en un lenguaje estándar, e ingresar en la aplicación (según corresponda). Responder a la capa de middleware si la
información ha terminado su proceso (inserción, edición, eliminación) correctamente dentro de la aplicación.
4.2.5 ALMACENAMIENTO (BDS)
Descripción: Zona en la cual se va a almacenar y se va a hacer persistente, toda la información que ha llegado hasta las bases de datos, dentro de esta
zona, se emplearán Bases de Datos (OLTP, OLAP)
Objetivo: Almacenamiento de la información ingresada por los diferentes canales
Responsabilidades: Garantizar que la información que llega aquí y que cumple con las diferentes reglas de negocio y constraints definidos por el Banco
de Los Alpes se están cumpliendo. Del mismo modo se debe garantizar la persistencia de los datos.
4.2.6 SISTEMAS DE ARCHIVOS
Descripción: Zona que permite que los archivos con los diferentes prospectos a ser evaluados por parte del banco sean procesados directamente por
las aplicaciones correspondientes . Aquí se emplearán técnicas como ETL (Extract, Transform and Load)
Objetivo: Enviar los registros directamente a la aplicación encargada de procesar la información.
Responsabilidades: Garantizar que los registros tienen el formato correcto.
4.3 VISTAS
Problema
4. Persistencia
3. Seguridad
2. Plataforma
1.
Proveedores
Externos
4.3.1 PROVEEDORES EXTERNOS
Objetivo: Identificar desde la perspectiva de los agentes externos a la aplicación su interacción con el sistema del Banco de Los Alpes, de mismo modo
identificar, los mecanismos utilizados para acceder a los servicios ofrecidos. Middleware (ESB) integración
Zonas: Proveedores, Conectores Middleware, Integración, aplicaciones, Realzadora.
Carrefour
Concesionarios de autos
Realzadora
Applicaciones
Integración
Middleware
Proveedores
Vista de proveedores externos
Almacenes Éxito
Constructoras
ESB
(Integrador)
Cargue
Prospectos
PartnersFileLoaderSystem
Administrar
Cliente
CRM
BlackListSystem
Consultar
Listas Negras
SavingsSystem
Aprobar
Producto
LoansCreditSystem
Activar
Producto
CredicardIntegratedSystem
ETL / BATCH
MakingFinantialProductSystem
JMS
SOAP
Sockets
4.3.2 PLATAFORMA
Objetivo: Visión de la parte lógica de todas las diferentes aplicaciones que el Banco de Los Alpes posee, también identificaremos los medios por los cuales
recibe información.
Zonas: Canales, Infraestructura de Red, Proxy Seguridad, Aplicaciones, Almacenamiento y Sistema de Archivos.
Canales
Vista de plataforma
Infraestructura de Red
IVR
Proxy Seguridad
Balanceador
de Cargas
JOSSO
JSSE
Portal
PartnersFileLoaderSystem
CustomerScoringSystems
BlackListSystem
CRM
SavingsSystem
LoansCreditSystem
BroadCastSystem
MakingFinantialProductSystem
Almacenamiento
Aplicaciones
Browser
ATM
Sistema de Archivos
OLTP
OLAP
HTTP
WS-Securiy
NFS
JDBC
Directorio Archivos
Planos
Filesystem Base de datos
Directorio RDBMS
ProductsDeliverySystem
4.3.3 SEGURIDAD
Objetivo: Describir la relaciones de los componentes de seguridad, protección de información sensible para el negocio, identificación de componentes de
seguridad que involucran la información de los usuarios y mostrar los elementos que pueden comprometer la privacidad de los clientes
Zonas: Canales, Conectores Middleware, Sistemas de Archivos, Aplicaciones, Almacenamiento
Canales
Vista de seguridad
IVR
Proxy Seguridad
Aplicaciones
Browser
ATM
JOSSO
JSSE
Portal
PartnersFileLoaderSystem
CRM
BlackListSystem
SavingsSystem
LoansCreditSystem
CredicardIntegratedSystem
HTTPS
WS-Security
4.3.4 PERSISTENCIA
Objetivo: Definir cuáles son las aplicaciones que van a estar interactuando con las diferentes bases de datos,
Zonas: Sistema de Archivos, Aplicaciones, Almacenamiento
Portal
PartnersFileLoaderSystem
Sistema de Archivos
Almacenamiento
Aplicaciones
Vista de persistencia
CustomerScoringSystems
BlackListSystem
OLTP
Directorio Archivos
Planos
CRM
SavingsSystem
LoansCreditSystem
BroadCastSystem
MakingFinantialProductSystem
ProductsDeliverySystem
OLAP
Directorio RDBMS
Flujo de peticion de Directorio Archivos Planos
Flujo de petición de Base de datos
Flujo de peticion de Filesystem Base de datos
Documentar relaciones entre elementos.
IVR. Protocolo remoting, permite crear aplicaciones ampliamente distribuidas, es decir, se pueden utilizar componentes (objetos) que estén en el
mismo equipo o que estén en cualquier parte de la red. Del mismo modo este protocolo permite separar la implementación de los métodos en
diferentes sistemas.
Identificar y documentar los requerimientos no funcionales
Encripción
Ws security
Reliable message
Certificados digitales
Canales seguros
Claves de acceso
LDAP políticas de vencimiento
Circular 052 de la superfinanciera para las entidades vigiladas por esta entidad
5. PORTAFOLIO DE SERVICIOS
5.1 IDENTIFICACIÓN DE SERVICIOS
5.1.1 ENFOQUE TOP-DOWN
Para identificar los servicios utilizando este enfoque partimos de los subprocesos de negocio identificados en la WBS que elaboramos en la arquitectura de
negocio. Leyendo esta estructura hacia abajo, pasando por las funcionalidades y los casos de uso, identificamos los siguientes servicios:






Depurar y Segmentar
Estudiar Crédito
Cargar Prospectos
Consultar Listas Negras
Administrar Cliente
Aprobar Producto
5.1.2 ENFOQUE BOTTOM- UP
Para identificar los servicios utilizando este enfoque partimos de las aplicaciones identificadas





Parametrizar Reglas de Segmentación
Parametrizar Factores de Evaluación
Administrar Cliente
Aprobar Producto
Activar Producto
5.1.3 ENFOQUE DE ARQUITECTURA
Para identificar estos servicios utilizamos los análisis de arquitectura realizados en talleres anteriores.
5.1.3.1
ARQUITECTURA DE NEGOCIO
Los servicios identificados bajo este enfoque son los siguientes:





5.1.3.2
Depurar y Segmentar
Estudiar Crédito
Cargar Prospectos
Parametrizar Reglas de Segmentación
Parametrizar Factores de Evaluación para Estudio de Crédito
ARQUITECTURA DE TECNOLOGIA
Los servicios identificados bajo este enfoque son los siguientes:





Localizar Servicio UDDI
Registrar Log de Auditoria
Registrar Eventos en el Dashboard
Localizar Nombres de Dominio
Autenticar contra Servidor LDAP
5.2 CATEGORIZACION DE SERVICIOS POR TAXONOMIA
5.2.1 SERVICIOS DE ENTIDAD
Los servicios de entidad son los siguientes:



Aprobar Producto
Administrar Cliente
Activar Producto
5.2.2 SERVICIOS DE FUNCIONALIDAD
Los servicios de funcionalidad son los siguientes:



Consultar Listas Negras
Parametrizar Reglas de Segmentación
Parametrizar Factores de Evaluación para Estudio de Crédito
5.2.3 SERVICIOS DE INFRAESTRUCTURA
Los servicios de infraestructura son los siguientes:




Registrar Eventos en el Dashboard
Localizar Servicio UDDI
Localizar Nombres de Dominio
Autenticar contra Servidor LDAP
5.2.4 SERVICIOS DE SISTEMA DE INFORMACION
Los servicios de sistema de información son los siguientes:



Registrar Eventos en el Dashboard
Localizar Servicio UDDI
Autenticar contra LDAP
5.2.5 SERVICIOS DE PROCESOS DE NEGOCIO
Los servicios de procesos de negocio son los siguientes:






Depurar y Segmentar
Estudiar Crédito
Cargar Prospectos
Consultar Listas Negras
Parametrizar Reglas de Segmentación
Parametrizar Factores de Evaluación para Estudio de Crédito
5.3 CONTRATOS DE LOS SERVICIOS
Los contratos de los servicios definen de forma clara la estructura de un servicio, su identificación, su propietario y como debe implementarse. Los contratos de
nuestros servicios son los siguientes:














Contrato Consultar Listas Negras
Contrato Administrar Cliente
Contrato Aprobar Producto
Contrato Activar Producto
Contrato Registrar Eventos en el Dashboard
Contrato Parametrizar Reglas de Segmentación
Contratos Parametrizar Factores de Evaluación para Estudio de Crédito
Contrato Localizar Servicio UDDI
Contrato Registrar Log de Auditoria
Contrato Localizar Nombres de Dominio
Contrato Autenticar contra Servidor LDAP
Contrato Procesar Pedido ATM
Contrato Procesar Pedido Portal
Contrato Procesar Pedido IVR
6
6.1
ARQUITECTURA DE SOLUCIÓN BAJO EL ESTILO DE ARQUITECTURA SOA
BLUEPRINT DE ARQUITECTURA NIVEL 1
6.2
DOCUMENTACIÓN ZONAS
6.2.1 ZONA DE CANALES
Esta zona agrupa los usuarios o clientes de las aplicaciones internas del Banco de los Alpes.



Canal ATM. Este canal hace referencia a los cajeros automáticos, desde los cuales los clientes podrán consultar el estado de sus productos, inactivar,
bloquear y cambiar la clave de sus productos
Canal Portal. Este canal hace referencia a los accesos de los clientes y usuarios de las aplicaciones del Banco de los Alpes, cuyo acceso se hace a través
de Internet.
Cana IVR. Este canal es el utilizado por los clientes del Banco de los Alpes, quienes a través de una aplicación de respuesta automática (menú de audio
respuesta) podrán acceder a diferentes funcionalidades, tales como: activación de productos, bloqueo de productos y cambios de clave
6.1.1 ZONA DE PROCESOS
Esta zona agrupa los subprocesos del proceso de Originación de Crédito que están asociados directamente con las tareas y funcionalidades del negocio.



Cargue de Prospectos. En este subproceso se encuentran las reglas de negocio que permiten el manejo del cargue de prospectos desde los archivos
que entregan los proveedores de información y la depuración de prospectos contra la Registraduria.
Depurar y Segmentar. En este subproceso se encuentran las reglas de negocio que permiten el manejo de la depuración de prospectos contra listas
negras y centrales de riesgo y segmentación de acuerdo al rango salarial y de gastos de los prospectos.
Estudiar Crédito. En este subproceso se encuentran las reglas de negocio que permiten el manejo de la creación y modificación de clientes en el CRM,
el estudio de crédito y la aprobación, creación y activación de productos
6.1.2 ZONA DE SERVICIOS
Esta zona agrupa los servicios que serán utilizados por las aplicaciones a nivel interno del banco. Estos se encuentran categorizados por funcionalidad, entidad e
infraestructura.

Servicios de Funcionalidad. Estos servicios están asociados con las tareas que soportan los procesos de negocio del Banco de los Alpes.
-
-


Parametrizar Rangos de Segmentación (S08). Por medio de este servicio el sistema permite la parametrización de las reglas de
segmentación para la validación de la información de los potenciales clientes.
Parametrizar Factores de Evaluación para estudio de crédito (S09). Se encarga de permitir configurar los factores de negocio
que me permiten calcular el score para el estudio de crédito.
Consultar Listas Negras (S01). Este servicio se encarga de consultar en los diferentes tipos de listas de riegos, los clientes
potenciales para los diferentes productos que ofrece el banco. Al final de la consulta del proceso el servicio informará como
primera medida si el cliente se encuentra o no en algunas de las listas restrictivas.
Servicios de Entidad. Estos servicios están asociados con las entidades que por gobernabilidad de datos, tienen la información de clientes y
productos del Banco
Aprobar Producto (S03). Por medio de este servicio el sistema permite la aprobación de productos de clientes en el sistema.
-
Administrar Clientes (S02). Este servicio se encarga de permitir la creación de los clientes del banco.
-
Activar Productos (S05). Por medio de este servicio el sistema permite la activación, bloqueo y cambios de clave de productos
Servicios de Infraestructura. Estos servicios están asociados a las plataformas de soporte que transversalmente son utilizados por las
aplicaciones del Banco.
Autenticar contra Servidor LDAP (S15). Realiza la autenticación de usuario contra un servidor LDAP o también puede cerrar
sesión.
-
Localizar Nombres de Dominio (S14). Permite conocer mediante el nombre del servidor su dirección ip para su ubicación.
6.1.3 ZONA DE PROVEEDORES
Esta zona agrupa las aplicaciones proveedoras de información que son utilizadas por los procesos de negocio del Banco para la administración de clientes y
productos.
 PartnersFileLoaderSystem. Este sistema tiene como principales responsabilidades:







o Cargar sobre un modelo de datos relacional los archivos planos que llegan desde los diferentes proveedores de clientes prospectos.
o Validar que la información de clientes prospectos sea real de acuerdo a la Registraduria General de la Nación.
CustomerScoringSystems. Es el sistema de información usado por el área de riesgo del Banco para depurar y segmentar los clientes
prospectos de acuerdo a varias validaciones.
BlackListSystem. Es el sistema que permite almacenar y administrar las listas negras locales y las externas como: Lista Clinton y Lista
Antilavado.
Esta aplicación también suponemos que nos permitirá el almacenamiento y administración de la información de centrales de riesgo tales
como CIFIN y DATACREDITO.
CRM. Es el sistema que permite la administración de la información de los clientes. Así mismo en este se realiza el estudio de crédito de los
clientes, antes de la pre aprobación de productos.
CredicardIntegratedSystem. Este sistema permite el almacenamiento y administración de la información asociada a tarjetas de crédito.
LoansCreditSystem. Este sistema permite el almacenamiento y administración de la información asociada a los créditos de libre inversión.
SavingSystems. Este sistema permite el almacenamiento y administración de la información asociada a las cuentas de ahorros.
6.1.4 ZONA DE DATOS
Esta zona agrupa las bases de datos asociadas a cada una de las aplicaciones proveedoras del Banco. Estas bases de datos son categorizadas en dos grupos:
OLTP y OLAP.

OLTP (OnLine Transaction Processing). Estas facilitan y administran aplicaciones transaccionales, usualmente para entrada de datos y recuperación
y procesamiento de transacciones.

OLAP (OnLine Analytical Processing). Utilizada para agilizar la consulta de grandes cantidades de datos. Para ello utiliza estructuras
multidimensionales (o Cubos OLAP) que contienen datos resumidos de grandes Bases de datos o Sistemas Transaccionales (OLTP). Se usa en
informes de negocios de ventas, marketing, informes de dirección, minería de datos y áreas similares.
6.2.6 DIALECTO DE DATOS CANONICO
En la siguiente tabla se identifican los tipos de datos propuestos para los canales, al momento en que estos se autentican y entran en contacto con la zona de
servicios.
Sistema / Canal
ATM
IVR
Portal
Dato Propietario
Base 24
Remoting
HTTP
Mensaje
Dato Canónico
Destino
Cambio de Clave
XML (SOAP)
Servicio Activar
Producto
Bloqueo de Producto
XML (SOAP)
Servicio Activar
Producto
Cambio de Clave
XML (SOAP)
Servicio Activar
Producto
Activación de Producto
XML (SOAP)
Servicio Activar
Producto
Bloqueo de Producto
XML (SOAP)
Servicio Activar
Producto
Actualización de Información
XML (SOAP)
Servicio Activar
Producto
Cambio de Clave
XML (SOAP)
Servicio Activar
Producto
Activación de Producto
XML (SOAP)
Servicio Activar
Producto
Bloqueo de Producto
XML (SOAP)
Servicio Activar
Producto
Actualización de Información
XML (SOAP)
Servicio Activar
Producto
En cuanto a la estructura de los mensajes se definieron los siguientes XSD que soportan ENTIDADES y MENSAJES


XSD Cliente
XSD Producto


6.3
XSD Consultar Listas Negras
XSD Activar Producto
BLUEPRINT DE ARQUITECTURA NIVEL 2
6.4 DOCUMENTACIÓN DE SERVICIOS Y ADAPTADORES (RNF)
6.4.1 SERVICIOS NO FUNCIONALES
Estos servicios son utilizados por los sistemas del Banco para soportar su operación. Estos son transversales y pueden ser invocados en cualquier momento:



Registrar Log de Auditoria (S11). Nos permite registrar eventos y actividades de determinadas acciones realizadas en el sistema, con datos como la
fecha, hora quien hizo la acción sobre q sistema y que acción.
Registro de Eventos en el Dashboard (S07). Por medio de este servicio el sistema permite el registro de información importante para la toma de
decisiones en la gerencia de la organización
Localizar Servicios – UDDI (S10). Se implementa la funcionalidad de búsqueda de los servicios de acuerdo a unos tags que recibe como parámetro para
ser usados en la implementación de estos.
6.4.2 SERVICIOS TIPO ADAPTADOR (ABCS)
Estos servicios son utilizados por los canales para acceder a los servicios de las aplicaciones del Banco.

Procesar pedido ATM. Este conector permite que el canal correspondiente a los cajeros del banco que envían datos propietarios Base 64 puedan pasar
a un tipo de datos canónico que se puede manejar en la zona SOA. Este servicio permitirá redireccionar los mensajes que se lean desde los cajeros, en
lo concerniente a bloqueo de productos y cambios de clave que soliciten los clientes del Banco.

Procesar pedido Portal. Este conector permite que el canal correspondiente a los clientes que utilizan el portal del banco y que envían datos por el
protocolo HTTP, puedan pasar a un tipo de datos canónico que se puede manejar en la zona SOA. Este servicio permitirá redireccionar los mensajes
que se lean desde el portal del banco, en lo concerniente a actualización de datos, activación de productos, bloqueo de productos y cambios de clave.

Procesar pedido IVR. Este conector permite que el canal correspondiente a las llamadas que ingresan al sistema de audio respuesta y que envían datos
propietarios Remoting, puedan pasar a un tipo de datos canónico que se puede manejar en la zona SOA. Este servicio permitirá redireccionar los
mensajes que se lean desde el portal del banco, en lo concerniente a actualización de datos, activación de productos, bloqueo de productos y cambios
de clave.
6.4.3 SOPORTE DE LOS REQUERIMIENTOS NO FUNCIONALES
En la arquitectura se plantean varios componentes que soportan los requerimientos no funcionales tales como multicanalidad, transaccionalidad, seguridad y
manejo de excepciones.

Multicanalidad. Esta es soportada por los conectores que se encuentran en su correspondiente zona. La idea es que estos conectores transformen los
datos propietarios de cada uno de los canales a datos canónicos que puedan ser entendidos por los procesos que se encuentran en la zona SOA.

Transaccionalidad. En el blueprint se pueden apreciar en que zonas se encuentran identificadas las transacciones que son procesadas por los sistemas
del banco (En el blueprint se pueden apreciar los componentes TX).
o
o
o
o
o
Transacciones para la creación de parámetros de segmentación
Transacciones para la actualización de registros en las listas negras
Transacciones para la creación, actualización y modificación de los datos de los clientes
Transacciones para la aprobación de productos
Transacciones para la activación de productos
Así mismo se tiene la identificación de los puntos en donde se debe exigir el enfoque Two Phase Commit (2PC). Este enfoque nos permitirá manejar
confirmación para el registro efectivo de las transacciones en las bases de datos si todos los eventos de registro fueron exitosos. La idea es que si en un
evento que requiere aplicar cambios sobre dos o más tablas este se haga completamente y no parcialmente, garantizando la integridad de la información
del sistema. Para nuestro caso particular se tienen los siguientes





2PC. Controlar la actualización de la información del cliente en lo referente a los eventos en los que se tiene que actualizar el estado de los productos
del cliente tanto en el CRM como en los sistemas de tarjeta de crédito, crédito de libre inversión y cuenta de ahorros.
2PC(1). Controlar la actualización de la información del los productos de tarjeta de crédito en lo referente a los eventos en los que se tiene que
actualizar el estado de los productos y de la información del cliente en el CRM.
2PC(2). Controlar la actualización de la información del los productos de crédito de libre inversión, en lo referente a los eventos en los que se tiene que
actualizar el estado de los productos y de la información del cliente en el CRM.
2PC(3). Controlar la actualización de la información del los productos de cuenta de ahorros, en lo referente a los eventos en los que se tiene que
actualizar el estado de los productos y de la información del cliente en el CRM.
Seguridad. Esta es soportada por el servicio denominado Autenticar LDAP cuya finalidad es centralizar mediante un directorio común de acceso a
cualquier aplicación, la autenticación del usuario para permitir validar el perfil y el nivel de acceso que este puede adoptar.

Manejo de Excepciones. . En el blueprint se pueden apreciar en que zonas se encuentran identificadas las generaciones de excepciones (G), que se
pueden dar como producto de la no finalización de una transacción. Para nuestro caso, identificamos los siguientes:
o Excepciones a nivel de CustomerScoringSystem. Esta puede aparecer al momento de registrar los parámetros de segmentación de prospectos.
Su propagación deberá hacerse hasta el proceso que lo origino con el fin de que una persona la vea y tome alguna acción.
o Excepciones a nivel de BlackListSystem. Esta puede aparecer al momento de registrar en la base de datos de listas negras y centrales de
riesgo. Su propagación deberá hacerse hasta el proceso que lo origino con el fin de que una persona la vea y tome alguna acción.
o Excepciones a nivel de CRM. Esta puede aparecer al momento de registrar en la base de datos del CRM modificaciones a los registros de los
clientes. Su propagación deberá hacerse hasta el proceso y/o canal que lo origino con el fin de que una persona la vea y tome alguna acción.
o Excepciones a nivel de CreditCardIntegratedSystem. Esta puede aparecer al momento de registrar en la base de datos del sistema de tarjeta
de crédito modificaciones a los registros de los productos. Su propagación deberá hacerse hasta el proceso y/o canal que lo origino con el fin
de que una persona la vea y tome alguna acción.
o Excepciones a nivel de CreditCardIntegratedSystem. Esta puede aparecer al momento de registrar en la base de datos del sistema de tarjeta
de crédito modificaciones a los registros de los productos. Su propagación deberá hacerse hasta el proceso y/o canal que lo origino con el fin
de que una persona la vea y tome alguna acción.
o Excepciones a nivel de LoanCreditSystem. Esta puede aparecer al momento de registrar en la base de datos del sistema de crédito de libre
inversión modificaciones a los registros de los productos. Su propagación deberá hacerse hasta el proceso y/o canal que lo origino con el fin
de que una persona la vea y tome alguna acción.
o Excepciones a nivel de SavingsSystem. Esta puede aparecer al momento de registrar en la base de datos del sistema de cuentas de ahorros,
modificaciones a los registros de los productos. Su propagación deberá hacerse hasta el proceso y/o canal que lo origino con el fin de que una
persona la vea y tome alguna acción.
o Excepciones a nivel de PartnerFileLoaderSystem. Esta puede aparecer al momento de cargar los listados entregados por los proveedores en la
base de datos del sistema de cargue de archivos. Su propagación deberá hacerse hasta el proceso que lo origino con el fin de que una persona
la vea y tome alguna acción.
7
LECCIONES APRENDIDAS
1.
2.
3.
4.
5.
6.
7.
8.
9.
El trabajo en equipo es fundamental para analizar un problema desde varios puntos de vista
Es importante adoptar estándares comunes entre todos los miembros de un equipo de trabajo
No desechar observaciones y puntos de vista distintos a los propios
Organizar el trabajo a través de métodos de registro de información y planeación, seguimiento y control del mismo, nos disciplina y ayuda a conducir
nuestro trabajo de una forma clara y precisa.
Por medio de la utilización de repositorios comunes se puede agilizar en procesos de integración de información
Definir desde el principio claramente las tareas de cada miembro del grupo de trabajo
Los entregables deben estar listos al menos con un día de anticipación para evitar confusiones y extravíos de información a la hora de las entregas
Es importante tener bien identificados los procesos de negocios para que la solución planteada sea acorde y verdaderamente cumpla las expectativas
del cliente
Se debe tener una vista general de todo el proyecto para que se pueda atacar con varios puntos de vista
8. CONCLUSIONES
1.
2.
3.
4.
5.
6.
7.
Por medio de un análisis detallado y muy lógico del problema presentado se puede abstraer en diferentes vistas cada uno de los componentes de un
problema
La adopción de metodologías es importante para esquematizar y descomponer un problema complejo.
Se requiere un gran conocimiento de diferentes tecnologías y aplicaciones para definir las aplicaciones o soluciones necesarias para llegar a la solución
propuesta
La utilización de diferentes puntos de vista para la especificación de un estilo de arquitectura, permite consolidar en ultimas un modelo integral de
arquitectura más aproximado a una solución optima.
La utilización de varios enfoques al momento de definir servicios, nos permite abordar con mayor precisión la tarea de la identificación de servicios
Los diagramas de arquitectura (blueprint) deben ser los suficientemente claros como para prever el comportamiento futuro de nuestra solución.
El análisis detallado de todos los elementos de una vista o arquitectura nos permite identificar con mayor exactitud el verdadero objetivo y utilidad de
tales elementos dentro de una solución.
9. BIBLIOGRAFÍA
-
http://www.opengroup.org/architecture/togaf9-doc/arch/
http://wikipedia.org/
http://msdn.microsoft.com/es-es/library/kwdt6w2k(VS.80).aspx
http://es.wikipedia.org/wiki/Cajero_autom%C3%A1tico
http://es.wikipedia.org/wiki/Enterprise_service_bus
http://www.w3schools.com/soap/soap_intro.asp
Java(TM) Message Service Specification Final Release 1.1 extraido de la URL: https://cds.sun.com/is-bin/INTERSHOP.enfinity/WFS/CDSCDS_Developer-Site/en_US/-/USD/ViewFilteredProducts-SimpleBundleDownload
http://es.wikipedia.org/wiki/Java_Message_Service
http://es.wikipedia.org/wiki/OLAP