Este documento presenta las arquitecturas de dos sistemas financieros complejos desarrollados por Mercap. La primera solución utiliza una arquitectura modular dividida en sistemas, mientras que la segunda incorpora un motor de workflow embebido. Ambas soluciones permiten mantener un código único para todos los clientes y configurar procesos de negocio de forma dinámica sin necesidad de cambios de código. Además, la segunda solución facilita la auditoría de procesos al registrar la historia de ejecución de cada workflow.

1. XTrade
Arquitectura de un Sistema
Financiero Complejo
Gabriel Omar Cotelli
g.cotelli@mercapsoftware.com

2. Agenda
●¿Qué es un Sistema Financiero?
●¿Por qué es complejo?
●Objetivos que nos Propusimos
○Soluciones Estandar a dichos Objetivos
○Nuestra Solución
■Arquitectura de Sistemas
■Workflow
○Un Resultado inmediato:
■Auditoria
●Conclusiones

3. Introducción

4. ¿Quiénes somos?
●Mercap
○Empresa de desarrollo de software financiero
○12 años desarrollando sistemas con Smalltalk
○Productos:
■Unitrade Bancos
■XTrade Fondos, AFJPs, Seguros, etc.
○Desarrollo con metodologías ágiles

5. ¿Qué es un Sistema Financiero?
Sucursales
Bloomberg
Siopel

6. ¿Por qué es complejo?
●Funcional:
○Muchos usuarios concurrentes
○Múltiples Transacciones
○Integración variada
○On-Line / Batch
●Desarrollo:
○11.825 Clases
○650.616 Líneas de Código
○15.424 Casos de Test de Unidad

7. Objetivos

8. Objetivos de Arquitectura
●Facilitar la interacción entre
○Departamentos del cliente
○Con sistemas existentes
●Escalable y Confiable
●Permitir que cada cliente tenga sus propios
procesos de negocio
●Poder asignar roles y permisos a cada tarea
dentro de un proceso de negocio
●Tener una auditoria de procesos detallada
●Otros Objetivos relacionados con el negocio

9. Objetivos de Desarrollo
●Que la extensión del sistema sea mediante la
creación de nuevos objetos, nuevos módulos
●Aislar la funcionalidad de negocio del núcleo del
sistema
●Separación de asuntos transaccionales de la
lógica de negocio
●Poder correr el sistema indistintamente en
Visual Age Smalltalk y GemStone/S
●Código único para todos los clientes
●Otros relacionados con diseño y metodología

10. Solución estándar

11. Código por cada cliente
registerPurchase: aPurchase
self registerAsPending:aPurchase.
self askForConfirmationOf: aPurchase.
self settle: aPurchase
registerPurchase: aPurchase
self registerAsPending: aPurchase.
self confirm: aPurchase.
Cliente
A
Cliente
B
registerPurchase: aPurchase
…..
Otros Clientes

12. Código único con decisiones
explícitas
registerPurchase: aPurchase
self registerAsPending:aPurchase.
(client = #ClientA)
ifTrue: [
self askForConfirmationOf: aPurchase.
self settle: aPurchase].
(client = #ClientB)
ifTrue: [
self confirm: aPurchase]
…. “More clients…”

13. Problemas
●Costoso de mantener
●Difícil compartir mejoras o arreglos entre
clientes
●Cambios en un cliente pueden afectar a
otro cliente
●Etc…
●En conclusión: Solución sin utilizar objetos

14. Solución 1:
Arquitectura modular
dividida en sistemas

15. Objetivos a nivel sistema
●Facilitar la interacción entre
○Departamentos del cliente
○Con sistemas existentes
●Escalable y Confiable
●Permitir que cada cliente tenga sus propios
procesos de negocio
●Poder asignar roles y permisos a cada tarea
dentro de un proceso de negocio
●Tener una auditoria de procesos detallada
●Otros Objetivos relacionados con el negocio

16. Objetivos de Desarrollo
●Que la extensión del sistema sea mediante la
creación de nuevos objetos, nuevos módulos
●Aislar la funcionalidad de negocio del núcleo del
sistema
●Separación de asuntos transaccionales de la
lógica de negocio
●Poder correr el sistema indistintamente en
Visual Age Smalltalk y GemStone/S
●Código único para todos los clientes
●Otros relacionados con diseño y metodología

17. Diseño
●Sistema: objeto que encapsula funcionalidad de
alto nivel. Ejemplo:
○Sistema de Clientes
○Sistema de Cotizaciones
●Cumplen con una interfaz específica
●Pueden existir distintas implementaciones
dependiendo del cliente. Ejemplo:
○Sistema de Cotizaciones de Bloomberg
○Sistema de Cotizaciones de Reuters

18. Diseño
●XTrade es una composición dinámica de
Sistemas que:
○Agrupa la instalación específica del cliente
○Permite cambiar dicha instalación on-the-fly
●Se conocen entre sí por un mecanismo de
dependencias que:
○Asegura la correcta configuración de la
implementación
○Permite un inicio y detención seguro y armonioso

19. Demostración Práctica

20. Resultado
XTrade
Sist. de
Tiempo
Sist. de
Bonos
CotizacionesBloo
mberg
Sist. de
Workflow
Instalación Cliente A
XTrade
Sist. de
Tiempo
CotizacionesReute
rs
Sist. de
Workflow
Instalación Cliente B

21. Solución 2:
Workflow Embebido

22. Objetivos a nivel sistema
●Facilitar la interacción entre
○Departamentos del cliente
○Con sistemas existentes
●Escalable y Confiable
●Permitir que cada cliente tenga sus propios
procesos de negocio
●Poder asignar roles y permisos a cada tarea
dentro de un proceso de negocio
●Tener una auditoria de procesos detallada
●Otros Objetivos relacionados con el negocio

23. Objetivos de Desarrollo
●Que la extensión del sistema sea mediante la
creación de nuevos objetos, nuevos módulos
●Aislar la funcionalidad de negocio del núcleo del
sistema
●Separación de asuntos transaccionales de la
lógica de negocio
●Poder correr el sistema indistintamente en
Visual Age Smalltalk y GemStone/S
●Código único para todos los clientes
●Otros relacionados con diseño y metodología

24. ¿Qué es un Workflow?
●La automatización de un proceso de
negocio en el cual la información,
documentos o tareas son pasadas de un
actor a otro para que este tome acciones
de acuerdo a los procedimientos definidos
por la organización

25. Ejecución de un proceso de
Workflow
Registrar
Compra de
Acciones
Liquidar
Compra
Enviar Mail
notificando
Confirmación
Confirmar
Compra de
Acciones
confirmad
a
rechazad
a

26. Ejecución de un proceso de
Workflow
Registrar
Compra de
Acciones
Liquidar
Compra
Enviar Mail
notificando
Confirmación
Confirmar
Compra de
Acciones
confirmad
a
rechazad
a
Front Office

27. Ejecución de un proceso de
Workflow
Registrar
Compra de
Acciones
Liquidar
Compra
Enviar Mail
notificando
Confirmación
Confirmar
Compra de
Acciones
confirmad
a
rechazad
a

28. Ejecución de un proceso de
Workflow
Registrar
Compra de
Acciones
Liquidar
Compra
Enviar Mail
notificando
Confirmación
Confirmar
Compra de
Acciones
confirmad
a
rechazad
a
Middle Office

29. Ejecución de un proceso de
Workflow
Registrar
Compra de
Acciones
Liquidar
Compra
Enviar Mail
notificando
Confirmación
Confirmar
Compra de
Acciones
confirmad
a
rechazad
a

30. Ejecución de un proceso de
Workflow
Registrar
Compra de
Acciones
Liquidar
Compra
Enviar Mail
notificando
Confirmación
Confirmar
Compra de
Acciones
confirmad
a
rechazad
a

31. Ejecución de un proceso de
Workflow
Registrar
Compra de
Acciones
Liquidar
Compra
Enviar Mail
notificando
Confirmación
Confirmar
Compra de
Acciones
confirmad
a
rechazad
a
Actor Automatizado Back Office

32. Ejecución de un proceso de
Workflow
Registrar
Compra de
Acciones
Liquidar
Compra
Enviar Mail
notificando
Confirmación
Confirmar
Compra de
Acciones
confirmad
a
rechazad
a

33. Ejecución de un proceso de
Workflow
Registrar
Compra de
Acciones
Liquidar
Compra
Enviar Mail
notificando
Confirmación
Confirmar
Compra de
Acciones
confirmad
a
rechazad
a

34. Demostración práctica: Editor
de Procesos de Workflow

35. Workflow de XTrade
Actores Interactivos
Actor
Automatizado
Actor
Automatizado

36. Demostración práctica

37. Escalabilidad
Cliente
Cliente
Cliente
Server

38. Escalabilidad
Cliente
Cliente
Cliente
Server
Cliente Cliente Cliente
Server

39. Escalabilidad
Cliente
Cliente
Cliente
Server
Cliente Cliente Cliente
Server
Cliente
Server

40. Conclusiones
●Se puede mantener el código único sin
decisiones explícitas en el mismo
●Al no estar hardcodeados los procesos de
la organización en el código permite
cambiarlos sin necesidad de nuevas
versiones
●Simplemente se reificaron conceptos que
antes no lo estaban

41. Un beneficio directo:
Auditoria

42. Objetivos a nivel sistema
●Facilitar la interacción entre
○Departamentos del cliente
○Con sistemas existentes
●Escalable y Confiable
●Permitir que cada cliente tenga sus propios
procesos de negocio
●Poder asignar roles y permisos a cada tarea
dentro de un proceso de negocio
●Tener una auditoria de procesos detallada
●Otros Objetivos relacionados con el negocio

43. Alternativas
●Codificar logging dentro de cada método
donde se quiera loguear
●Utilizar aspectos (pero…hay que definir
pointcuts, joinpoints, advices, etc….
mucho lio)

44. Nuestra solución
●Todo lo que un actor hace en el sistema
es ejecutar procesos
●Por ende, la auditoria consiste en guardar
la historia de ejecución de los procesos y
actividades de Workflow
●Reificación de la historia de procesos

45. Auditoria de un proceso en
ejecución
a
WorkflowHistor
ian
workflow
System
a Process
History Recorder
a Running
Process
historian
process

46. Demostración práctica

47. Conclusiones finales
●Arquitectura escalable
●Código único
●Configuraciones por cliente
●Menor costo de mantenimiento
●Desarrolladores más felices

48. ¿Preguntas?