Вы находитесь на странице: 1из 60

ENTREGA FINAL MODELAMIENTO- EMPRESA KALLSONYS

PRESENTADO A:

GERMAN ALONSO SUAREZ.

INTEGRANTES:
LUIS CARLOS HERNANDEZ
HECTOR DANIEL VICTORIA
NILSON MENDEZ
RICARDO TOSCANO

PONTIFICIA UNIVERSIDAD JAVERIANA


ESPECIALIZACIÓN EN ARQUITECTURA EMPRESARIAL DE SOFTWARE
BOGOTÁ, DICIEMBRE DE 2014
1. Visión de arquitectura

Definición de la VISIÓN DE AE.

El objetivo primordial de este proyecto es levantar la etapa de visión de arquitectura


Empresarial de alto nivel de la organización KALLSONYS. El propósito de este
proyecto de visión es generar un entregable de acuerdo a los requerimientos realizados
en conjunto KALLSONYS, su área de negocio especializada, área tecnológica e
interesados, junto con el equipo de arquitectura, enfocando estos requerimientos al
alcance esperado por la organización en cuanto a la pertinencia, completitud y enfoque
de este documento.

ALCANCE

El alcance de este proyecto de arquitectura empresarial que será desarrollado para la


empresa KALLSONYS en el proceso de comercialización de productos con
subprocesos divulgación catálogo de Productos, Cotización de Pedidos, Crear de
Órdenes de pedidos y seguimiento de Órdenes de Pedido, incluyendo también el tema
de modelo de distribución y establecimiento de comunicación con los Proveedores de
mensajería
.

Este proyecto se justifica puesto que la información de arquitectura genera


conocimiento a los interesados desde niveles gerenciales hasta niveles operativos,
permitiendo identificar el estado actual de su sistema, las falencias, capacidades y
oportunidades de mejora o cambio, y por tanto tomar decisiones que permitan alcanzar
los objetivos estratégicos de la organización.
DESCRIPCIÓN DEL PROCESO:

El proceso “Comercialización de productos” consiste en que el cliente tenga acceso a


un portal de compras para que realice su pedido por este medio, para que este cliente
tenga una experiencia satisfactoria de compra por la plataforma de Ecommerce.

DESCRIPCIÓN DEL PROBLEMA:

En el momento en que se crea.

OBJETIVO DE LA DECLARACIÓN DE ARQUITECTURA.

El objetivo de la declaración de arquitectura es identificar el estado actual de los


procesos de la empresa KALLSONYS, en especial el proceso “” para plantear una
estrategia de que permita atacar las falencias de ().

ALCANCE EN TIEMPO:
Se considera por el tamaño del proyecto un tiempo corto de iteracion (6 meses).

ALCANCE EN APLICACIÓN:
Modelamiento y Plan de integración de aplicaciones OMS y B2C.

ALCANCE EN DATOS:
Modelamiento empresarial de Datos e Información para Órdenes de Pedido y Catalogo
de Productos.

ALCANCE EN TECNOLOGÍA:
Infraestructura que soportará el despliegue de la implementación de las soluciones
OMS (sistema de pedidos) y B2C(portal).

ALCANCE EN NEGOCIO:
Soporte, optimización y apalancamiento a los procesos de Comercialización y Gestión
de Órdenes de Pedido.
VISTAS:

RESUMEN DEL NEGOCIO:

FUERZAS DEL MERCADO


OBJETIVOS DE NEGOCIO

- Definir del Proceso de Comercialización de Productos Sony en cuanto a generación,


seguimiento y ejecución de Órdenes de Pedido para la Empresa Kall Sony’s.

- Definir un modelo de e-commerce para la comercialización de productos Sony de la


empresa Kall Sony´s como intermediario de venta. Promoción y Mercadeo de
productos Sony a través de un modelo de Campañas orientadas a la sugerencia de
productos mas solicitados en ventas.

- Diseñar un modelo de integración mediante el cual la empresa Kall Sony’s pueda


interoperar con

- los fabricantes de Productos Sony, como La empresa matriz Sony y la bodega


de almacenamiento

- Rapid Services, discriminando la mejor opción de compra respecto a los costos


implícitos en el modelo de negocio.

- Plantear el modelo y esquema Arquitectural de aplicaciones necesarios para la


automatización y operación de cada uno de los procesos y requerimientos
requeridos por Kall Sony´s.

LIMITANTES

Aplicaciones

- Legados construidos en COBOL

- Se tiene como importante restricción de arquitectura y punto a tener en cuenta a


lo largo del modelado de la presente arquitectura que para el proceso de
contabilidad se cuenta con

- los fabricantes y el servicio de compras proveen Servicios Web que deberán ser
consumidos para cada una de las operaciones necesarias de cotización y orden
de pedido y pago por tarjeta respectivamente.

Implementacion:
- Services se debe desplegar como una solución Web, bajo una plataforma de
desarrollo .NET.
- El modelo e-commerce para que los usuarios puedan acceder a los servicios
brindados por Rapid
-
- El despliegue de las aplicaciones de Órdenes de Compras y Gestión de
Productos debe implementarse en un entorno de desarrollo Java.

- Se contempla la necesidad de un Motor de Procesos BPMS sobre el cual se


hará el despliegue e implementación del nuevo proceso del área comercial, que
albergará la ejecución de pedidos y seguimiento a órdenes.
- Se requiere un Enterprise Service Bus sobre el cual se hará el despliegue de los
servicios ofrecidos y requeridos para la ejecución de los procesos de negocios
de la empresa.

Comunicaciones

- La comunicación con el Proveedor de Mensajería Servientrega se limita a


registro de base de datos.

- Respecto a la comunicación para la generación de solicitud de entrega con


Deprisa será necesario la generación de Archivos CVS y envió de los mismos a
un directorio compartido por FTP.

- Por otra parte el proveedor DHL expone un servicio a través del cual se hace la
misma solicitud.

tiempo
- se tiene contemplado 6 meses

Economía:
- se hace un estimado de 450 millones. Repartido de la siguiente manera:

IDENTIFICACIÓN DE LOS INTERESADOS.


Figura 1. Organigrama KALLSONYS.

En cuanto a la toma de decisiones el conducto regular de las iniciativas de apoyo a los


proyectos sería así:

Figura 2. Estructura de gobierno actual KALLSONYS.

Según el organigrama actual de LEGIS los interesados serían en orden de gobierno:

1. GERENTE GENERAL.
2. GERENTE FINANCIERO
3. GERENTE COMERCIAL
4. GERENTE RRHH
5. Directores de departamento

Los involucrados en la aprobación financiera de los proyectos serían:


GERENTE GENERAL
GERENTE FINANCIERO
GERENTE COMERCIAL

REQUERIMIENTOS DE ALTO NIVEL DE LOS INTERESADOS.


- Evolucionar los procesos productivos de la empresa para que generen
rentabilidad por medio del uso de la tecnología y el mejoramiento continuo.

- Apalancar una estrategia de arquitectura empresarial que permita visualizar el


estado actual de los procesos, plantear mejoras sobre estos, y realizar
seguimiento del impacto de las mejoras sobre los procesos de mejora que se
implementaron como proyectos de arquitectura.

- Ser lider en el mercado de Colombia y crear sucursales en Latinoamérica

ANÁLISIS DE STAKEHOLDERS:

P B A) ESFUERZO MINIMO B) MANTENER


O a INFORMADO
D j
E o
R
A C) MANTENER SATISFECHO D) DOMINANTE
l
t
o

Bajo Alto

INTERES

PODER 1, ALTO
PODER 2, BAJO
INTERES 1, ALTO
INTERES 2, BAJO

INTERESADO INVOLUCRADO EN: TIPO

1. JUNTA DIRECTIVA. ESTRATEGIA C


TOMA DE DECISIONES
3. GERENTE GENERAL TOMA DE DECISIONES C
ESTRATEGIA

4. GERENTE TOMA DE DECISIONES C


FINANCIERO ESTRATEGIA

5. GERENTE COMERCIAL ESTRATEGIA B

6. GERENTE RRHH ESTRATEGIA A

7. DIRECTORES AREA ESTRATEGIA A

PROCESOS DE SEGUIMIENTO
Se realizarán reuniones semanales para monitorear el avance del proyecto.

DEFINICIONES DE FRAMEWORK DE ARQUITECTURA:


Se utilizará como base TOGAF con restricción de los artefactos entregados, los cuales
se evaluarán en cuanto a pertinencia con los interesados.

PLAN DE TRABAJO:

Actividades:
1. Levantamiento de la información
2. Realizar las fases planteadas en el framework de arquitectura escogido, para este
caso TOGAF
3. Realizar reuniones de socialización y avance del estado del proyecto con los
interesados.
4. Realizar y respaldar el termino de las fases con los documentos de entrega
respectivos indicados en el framework de arquitectura escogido

Entregables:
- Documentación de las fases respectivas
- Documento de arquitectura empresarial.(a nivel de VISION)
Riesgos

RIESGO SEVERIDAD MITIGACION

Selección de un alcance Alta Continua comunicación


muy alto en los objetivos con los interesados para
redefinir el alcance si es
necesario

Incumplimiento con las alta Seguimiento continuo del


fechas comprometidas y líder de arquitectura
entrega de los y
artefactos

Fuga de talento del alta Mantener la motivación


equipo de arquitectura del equipo.

Perdida de la información alta Mantener repositorios


respaldados del trabajo
realizado

Métricas e indicadores

métrica Medición unidad

Estatus del proyecto Porcentaje de avance ejecutado contra


esperado (plan)

desempeño Actividades ejecutadas contra


planeadas

Entrega de informes Artefactos entregados/ artefactos a


entregar
número de días que toma la entrega
contra número de días planeados
Encuesta de satisfacción Interesados satisfechos contra numero
de encuestados

Plan de comunicaciones

Se planea una reunión semanal de seguimiento del equipo de arquitectura, 1 reunión


mensual con los interesados, los avances de estas reuniones se divulgaran por correo
electrónico. Documentos escritos o medios magnéticos., los formatos a divulgar serán
Actas de reuniones, Memorandos, Actas de Compromisos e Informes de resultados.

Principios de Arquitectura

Dominio Arquitectura Negocio


1. Los principios definidos para el cumplimiento estratégico de la Arquitectura
Empresarial Priman.
2. Los procesos deben estar enfocados en lograr un alto impacto en los
rendimientos y beneficios económicos de la empresa.
3. La información involucrada y resultado de cada uno de los proceso se constituye
como fuente de análisis y búsqueda de ventajas competitivas.
4. La información es un componente determinante debe ser cuidada y reservada
por perfiles y contextos de negocio.

Dominio Arquitectura Negocio


5. aplicar estándares de integración SOA
6. aplicativos intuitivos en sus interfaces y orientados a usuarios de negocio

Dominio Arquitectura Tecnología

7. disminuir el costo de tecnologia y ser un aliado en el crecimiento y en la


optimizacion del negocio

DOCUMENTOS BORRADORES DE ARQUITECTURA


ARQUITECTURAS DE LÍNEA BASE

2. vistas AS IS (Negocio Aplicación Tecnología) archimate

3. vistas TO BE (Negocio Aplicación Tecnología) archimate


4. vista de procesos de negocio BPMN
5. Plantilla de proceso ATAM

1. identificación de escenarios de arquitectura (escenarios)


i. escenarios B2C

Escenario 001

Atributo de calidad DESEMPEÑO Concern Tasa de transacciones

Escenario {Número de transacciones por día}

Fuente de estímulo {Usuario Final}

Estímulo {Se desean realizar 3000 peticiones diarias distribuidas de la


siguiente manera
• Transacciones totales entre las 7:00 pm y 11:00 pm del 70%.
• El 30% de las transacciones entrara en las horas restantes.

Elementos del {Módulo de transacciones}


Sistema

Ambiente Bajo condiciones críticas de uso del sistema:


El supuesto de estas transacciones se da en el peor escenario
planteado por el cliente.
• Envío de 3000 peticiones diarias
• Recepción de 150 operaciones diarias de compras
(transaccionales).
• Back: Las conciliaciones de las transacciones se realizan por
la plataforma de back office, esta funcionalidad conciliara el 5%
de las transacciones.
• Riesgo: Con base en la información entregada por el cliente
los usuarios generales realizan el 70% de las transacciones se
realizan en un horario de 7:00 p.m a 11 p.m.

Respuesta del Se realizan las transacciones, complementaciones ,


Sistema conciliaciones y respuesta a cada una de las transacciones
consistentemente.

Medidas Soportar el envío de 3000 transacciones totales diarias,


Significativas de la repartidas así: 2100 en un intervalo de 4 horas y 900 en el resto
Respuesta del dia (20 horas.

Escenario 002

Atributo de calidad DESEMPEÑO Concern Tiempo de respuesta


transaccional

Escenario Tiempo de respuesta transaccional de las páginas

Fuente de estímulo Usuario final

Estímulo El sistema

Elementos del Portal


Sistema

Ambiente Bajo condiciones críticas de uso del sistema:


El supuesto de estas transacciones se da en el peor escenario
planteado por el cliente.
• Envío de 3000 transacciones diarias
• Riesgo: El 100% de las operaciones podrían necesitar de esta
funcionalidad.
• El 5% de los usuarios que ingresan al portal pueden realizar
compras generando carga transaccional.
Respuesta del Se realizan las transacciones, complementaciones y resolución
Sistema de tareas de manera consistente, según las descripciones
dadas en el estímulo.

Medidas El tiempo maximo de respuesta debe ser maximo de 5


Significativas de segundos.
respuesta

Escenario 003

Atributo de calidad EFICIENCIA Concern Tasa de respuesta de


navegación

Escenario El tamaño de cada página debe ser adecuado para


transacciones en el portal Web.

Fuente de estímulo Usuario final

Estímulo El tamaño máximo de cada página es de 60 kb y debe soportar


15 elementos.

Elementos del Portal


Sistema

Ambiente Bajo condiciones críticas de uso del sistema:


El supuesto de estas transacciones se da en el peor escenario
planteado por el cliente.
• Envío de XXX transacciones diarias
• Recepción de XXX transacciones diarias
• Riesgo: El 100% de las operaciones podrían necesitar de esta
funcionalidad.
• El 5% de los usuarios que ingresan al portal pueden realizar
compras generando carga transaccional.

Respuesta del Se realizan las transacciones, complementaciones y resolución


Sistema de tareas de manera consistente, según las descripciones
dadas en el estímulo

Medidas El tiempo maximo de respuesta debe ser maximo de 5


Significativas de segundos.
respuesta
Escenario 004

Atributo de calidad PORTABILIDAD Concern Adaptabilidad

Escenario El portal debe soportar diferentes plataformas de acceso.

Fuente de estímulo Usuario final

Estímulo El portal debe responder a plataformas, moviles , de escritorio y


a tecnologias de navegador distintas.

Elementos del Portal


Sistema

Ambiente El 100% de los formularios deben cumplir con diseño


adapatable a las diferentes formas de acceso a la pagina.

Respuesta del El portal B2C puede ser accedido y correctamente visulaizado


Sistema desde los diferentes terminales moviles, de escritorio y desde
diferentes navegadores

Medidas El 100 % de las plataformas pueden acceder a la plataforma.


Significativas de
respuesta

Escenario 005

Atributo de calidad EFICIENCIA Y Concern Alta disponibilidad


DESEMPEÑO

Escenario El 90% de hits de página tocan los datos del catálogo

Fuente de estímulo Usuario final

Estímulo El 90% de las peticiones son consultas al catálogo, lo que


significa que el tiempo total de una petición al catálogo debe ser
mucho menor que 5 segundos que es el tiempo máximo de
respuesta por petición, tiempo máximo de respuesta 2,5
segundos.
Elementos del Portal, OMS.
Sistema

Ambiente Este será el modulo que mayor carga tendra dentro del
sistema, se debe garantizar el desempeño óptimo durante las
transacciones concurrentes que va a recibir.

Respuesta del Se realizan las transacciones, complementaciones, las


Sistema transacciones que requieren datos del OMS responden en un
intervalo conveniente.

Medidas Las transacciones que involucran el catalogo responden en un


Significativas de tiempo inferior a 5 segundos.
respuesta

Escenario 006

Atributo de calidad SEGURIDAD Y Concern Confidencialidad y


CONFIABILIDAD disponibilidad

Escenario Gobierno de las cuentas de los clientes.

Fuente de estímulo Usuario final

Estímulo Las cuentas de los clientes que emplean la plataforma deben


tener las medidas requeridas de seguridad y respaldo de los
datos sensibles de los clientes .

Elementos del Portal, LDAP, Sistemas de redundancia de datos.


Sistema

Ambiente El sistema de be asegurar la administración segura de cada


una de las cuentas de usuario y debe tener sistemas de
replicación para asegurar la disponibilidad de los datos.

Respuesta del Se realizan las transacciones de forma segura, el sistema


Sistema posee mecanismos para responder a fallos de disponibilidad de
los datos.

Medidas Los incidentes de seguridad sobre las cuentas de los datos


Significativas de deben reducirse al 100%, la dispobilidad del ambiente debe ser
respuesta de 99.8% en el horario pico.
Escenario 007

Atributo de calidad CONFIABILIDAD Concern Confidencialidad

Escenario Manejo de sesiones en la compra.

Fuente de estímulo Usuario final

Estímulo El sistema debe ser capaz de mantener la sesion del cliente ,


una vez sea iniciado el proceso de compra (usuario decide
comprar los productos selccionados.

Elementos del Portal, LDAP, Sistemas de redundancia de datos.


Sistema

Ambiente El sistema de be asegurar la disponibilidad de la sesion del


cliente durante el proceso de compra con un tiempo maximo de
2 minutos por transacción ociosa y soportar la cantidad de
clientes que realizan la transacción en la plataforma.

Respuesta del Se mantienen las sesiones activas de compra de forma efectiva


Sistema , el sistema posee mecanimo para restaurar la sesion de
compra de usuario ante un fallo de comunicación en la
plataforma.

Medidas El XXX% de las transacciones de compra deben terminar


Significativas de correctamente.
respuesta

Escenario 008

Atributo de calidad OBSERVANCIA Concern Confidencialidad

Escenario Monitoreo Proactivo - Alertas/Notificaciones

Fuente de estímulo Usuario final

Estímulo El sistema realiza monitoreo Proactivo sobre las transacciones


realizadas sobre todo el sistema. En caso de ejecutarse alguna
transacción configurada como "inválida" o "no autorizada" o
"fallida", se debe enviar una alerta al administrador del sistema.

Elementos del Portal, LDAP, Sistemas de monitoreo y de logs eventos y


Sistema sucesos de la plataforma

Ambiente El sistema debe asegurar la traza completa de las


transacciones correctas y fallidas del sistema como medio de
observancia de logs y para auditoria de etsa transacciones

Respuesta del Se mantienen un registro de las transacciones, de los fallos de


Sistema la plataforma y se mantiene un esquema propicio para poder
realizar un auditoría del sistema

Medidas El 100% de las transacciones de compra fallidas deben tener


Significativas de su rastro de auditoría en todos los logs del sistema.
respuesta

2. Árbol de utilidad
3. decisiones de arquitectura

6. vistas 4+1 UML (vistas definidas por escenarios)


B2C Aplicación E-Commerce Documento de Arquitectura de Software

Documento de Arquitectura de Software

Introducción

Propósito

El objetivo de este documento es ofrecer una vista general de la Arquitectura del


sitio E-Commerce de ordenes de pedido de Kall Sony’s. Para lo cual nos hemos
apoyado de diferentes puntos de vista arquitectónicos para representar los
aspectos más significativos del sistema. El objeto de las diferentes vista es el de
dar a conocer las decisiones importantes de arquitectura que se han hecho en el
sistema.

Él presente documento es de carácter técnico y está dirigido a todos los


miembros del equipo de arquitectura y diseño, así como los desarrolladores,
gerentes del proyecto y aquellos otros que por sus funciones puedan resultar
interesados en su contenido:

 KALL SONY’S. Introducción y vista casos de uso.


 Arquitectos de software. Documento en general.
 Desarrolladores: Vista de Liberación y Capas.
 Integradores de soluciones: Encargados de asegurar la comunicación
entre los sistemas. Vista de procesos
 Personal de infraestructura: Vista de Despliegue

Alcance

El presente documento brinda una visión general del sistema, mostrando sus
características con respecto a los principios arquitectónicos y abarcando los
siguientes temas:

 Representación de la arquitectura: Describe qué es la arquitectura de


software del Sistema y cómo se representa.
 Vista de Casos de uso: Presenta los casos de uso arquitectónicamente
representativos del sistema, con el fin de tener un panorama global de la
solución y detectar el impacto de dichas funcionalidades en la arquitectura.

 Vista Lógica: Describe las partes significativas de la arquitectura en términos


de su descomposición en subsistemas y paquetes.

 Vista de Despliegue: Describe una o más configuraciones hardware y de red


sobre las cuales se ejecuta el Software.

 Vista de Implementación: Describe la estructura general del modelo de


implementación, la descomposición del software en capas y subsistemas en
el modelo de implementación y los componentes más significativos de la
arquitectura.

Definiciones, Acrónimos, y Abreviaciones

B2C Aplicativo E-Commerce para Ordenes de pedido


ESB Bus de servicios
E- Consiste en la compra y venta de productos o de servicios a través
Commerce de medios electrónicos, tales como Internet y otras redes
informáticas
UML Es un el lenguaje de modelado de sistemas de software más
conocido y utilizado en la actualidad; está respaldado por el OMG
(Object Management Group)

Referencias

 Modelado final - RequerimientosKS-B2C


 Modelado final - InformacionProyectoKS

Visión General

El presente documento está estructurado de la siguiente manera: representación


arquitectónica, metas y restricciones de la arquitectura, presentación de las 4+1 vistas.
Representación Arquitectónica

Las vistas se representarán utilizando los siguientes recursos:

• Vista de Casos de Uso.

Se representan las funcionalidades generales del sistema por medio de


diagramas de Casos de uso con la notación UML. La descripción detallada
de cada uno de los casos de uso no está en el alcance de este documento.

• Vista Lógica.

Se realiza el Modelo Conceptual de la plataforma, que permite comprender el


dominio del problema, Para tal efecto, se desarrolla un diagrama de las
diferentes capas y subsistemas lógicos que representan el universo del
sistema con notación UML.

• Vista de Implementación.

Se detalla la estructura que describe el modelo de implementación de la


aplicación, su composición y cada uno de sus componentes por medio del
Diagrama de Componentes con notación UML, describiendo los patrones y
frameworks involucrados en la arquitectura planteada.

• Vista de Despliegue

Se muestra la relación de la aplicación a desarrollar, con el hardware


requerido para el despliegue del sistema. Se utilizará el Diagrama de
Despliegue en notación UML.

• Vista de Procesos.

Se muestra el flujo de comunicación entre los componentes más


significativos del sistema. Se utilizará el Diagrama de Secuencia con notación
UML.
Vista Casos de Uso

cd Casos de Arquitectonicos

E-Commerce

Intercambiar
Informacion ESB

Autenticar Usuario

Web Front

Encritar datos
Tarj eta Credito

Iniciar
Orquestacion
Ordenes

ESB

Los casos de usos arquitectónicamente significativos son:

 Intercambiar Información ESB: Es de gran importancia definir la estrategia de


comunicación del sistema a través del ESB, garantizando que la decisión
asumida no afecte el performance de la aplicación E-Commerce.

 Autenticación del Usuario: La estrategia tomada sobre como la aplicación E-


Commerce autentique a los clientes debe garantizar la seguridad necesaria para
proteger la información del cliente.

 Cifrar datos Tarjeta de crédito: Es de gran importancia asegurar la


confidencialidad de los datos de la tarjeta de crédito, asegurando un método
seguro de encriptación de datos, se deberá definir el método de encriptación
adecuado sin que esto afecte el performance de la aplicación.

 Iniciar orquestación Ordenes: Se deberá realizar un análisis en el flujo de interno


de las ordenes de pedido, garantizando que se cumplan con los objetivos del
negocio sin afectar el rendimiento de a aplicación.

Vista de Procesos

Con el fin de presentar la interacción entre los componentes más


representativos de la arquitectura, en esta sección se presenta la comunicación
entre procesos.

cd Procesos

«proccess» «proccess»
«<<procces>>»

Brow ser Web Serv er Database Serv er

«procces» «<<process>>»

ESB Serv icios

Con esta vista se representan los siguientes procesos:


• Un proceso corriendo en el cliente que es un navegador que contiene la
interfaz de usuario, por la cual se accederá el sistema de E-Commerce de
Kall Sony´s.
• Un proceso en el servidor de aplicaciones (web server), el cual esta a la
espera de peticiones por parte de un cliente y responde a estas peticiones
adecuadamente.
• Un proceso en el servidor de ESB (bus de servicios), en el cual se
encuentran centralizados los servicios, este recibe solicitudes del servidor
de aplicaciones y las gestiona.
• Una vez el servidor de ESB recibe la solicitud y redirección al servicio
determinado, cada servicio accederá a base de datos según lo necesite.

Vista Despliegue

A continuación se muestra un diagrama de despliegue, que muestra la


distribución de las componentes Hardware de la aplicación.
cd Vista de Despliegue

WebServ er

{Win. 2008 Server}


{IIS 7}
Ciente

View B2C
WEB Cliente

«library» «library» «library»


Vista B2C Vista Catalogos Vista Segumiento

«executable»
Brow ser
Controller B2C
HTTPS

Controller B2C

«library»
Modulo -B2C

Model B2C

«library» «library» «library»


Seguridad Business Catalogos Business Ordenes

«library»
ESB Controller
Serv idores de Base datos

{Win 2008}
TCP-IP {SQL Server 2005}

TCP-IP

ESB

{Win Server 2008} Serv idor de Bae de datos


{BMPS}
{solaris}
TCP-IP
{Oracle}

«library» «library» «library» «library»


Adaptador Adaptador de Adaptador Adaptador
Serv icios Menaj eria Prov eedores Bancos

Características generales:
 Los componentes de la capa de presentación y Negocios corren dentro
del mismo servidor de aplicaciones (web server).

 Todos los servicios de integración a otros sistemas están centralizados en


el Bus de datos empresarial que es el componente que maneja los
detalles de la comunicación con la lógica de negocio de los diferentes
componentes, permitiendo así que las capas superiores no se vean
afectadas por cambios en estas implementaciones.

 Cada servidor tiene un rol definido (Web, Base de datos, aplicación), que
permite hacer extensible y mantenible la infraestructura, sin afectar otras
capas de la aplicación.

 Cada servicio en el ESB implementará la lógica de negocio requerida,


implementando el consumo de datos que se encuentran en los diferentes
repositorios, según sea su necesidad.

Vista Implementación

A continuación se presentan las diferentes piezas físicas de la aplicación y su


posición en las diferentes capas lógicas definidas para el sistema.

od Diagrama de Implementacion

BackEnd

Entidades Financieras

ManagerBanco WS-ValidarTarjetaCredito

WS.RegistrarPago
WebFront

Prov eedores

KallSonyView

Seguridad Layer Serv icios Layer

ManagerProv eedores Datos


1 *
WS.Proveedor
KallSonyController ESB-EComerce
Seguridad

Acceso a Datos
Mensaj eria

KallSonyModel

ManagerMensaj eria
1 *
WS.Mensajeria

FTP-Transfer

Productos

MnagerProductos ManagerOrdenes

Visión general

Las 4 capas que definen la arquitectura del sistema son: Presentación, Negocio,
Servicios y Datos.
WEB Front:

Esta capa comprende las páginas HTML creadas para la administración de las
órdenes de pedido y su seguimiento por parte de los clientes.
En su interior incorpora las capas de presentación, modelos y controladores
necesarios para su implementación.

Capa de Seguridad:

Esta capa es transversal a toda la solución e implementa los métodos


necesarios para garantizar la confidencialidad e Integridad de los datos.

Capa de Servicios:

Contiene las interfaces que permiten acceder a los servicios que proveen la
lógica de cada uno de los componentes de negocio. Esta capa se apoya el ESB
para la administración de los servicio.

Capa Back-End:

Incluye todo el modelo de las capas de negocio de Kall Sony´s, y el acceso


directo a cada uno de los sistemas que proveen las funcionalidades necesarias
para la aplicación E-Commerce, cada una de estas capas expone sus
funcionalidades como servicios, las cuales son administradas en el ESB.

Capa de datos:
Incluye los repositorios de datos de las aplicaciones persistidas en las diferentes
bases de datos legadas. Productos (SQL Server) y Clientes-Ordenes (Oracle).
Vista de Datos
Tamaño y Desempeño

La arquitectura propuesta busca optimizar el consumo de las aplicaciones del


back-end, minimizando el llamado entres las diferentes capas.
La solución propuesta debe estar en la capacidad de atender un promedio de
visitas de 219 usuarios concurrentes, sin que este se vea afectado en su tasa
de respuesta, la cual debe no ser mayor a los 5 segundos por solicitud.
La aplicación debe tener una disponibilidad del 99.99% al año. Considerando
únicamente ventanas de mantenimiento.

Calidad

La aplicación está diseñada por capas, de tal manera que las capas superficiales
la capa lógica y de comunicación. Cada capa se comunica con la capa que esté
directamente por debajo o sobre ella. No existen saltos de acceso entre capas
de manera tal que se mantenga una eficiente comunicación entre ellas.
OMS Aplicación de manejo de productos y órdenes Documento de Arquitectura
de Software

Documento de Arquitectura de Software


Introducción

Propósito
Este documento ofrece un panorama completo de la arquitectura del sistema de
manejo de productos y ordenes (OMS), usando un número de diferentes puntos
de vista arquitectónicos para representar diferentes aspectos del sistema. Su
objetivo es captar y transmitir las decisiones importantes de arquitectura que se
han hecho en el sistema
Él presente documento es de carácter técnico y está dirigido a todos los
miembros del equipo de arquitectura y diseño, así como los desarrolladores,
gerentes del proyecto y aquellos otros que por sus funciones puedan resultar
interesados en su contenido:

 KALL SONY’S. Introducción y vista casos de uso.


 Arquitectos de software. Documento en general.
 Desarrolladores: Vista de Liberación y Capas.
 Integradores de soluciones: Encargados de asegurar la comunicación
entre los sistemas. Vista de procesos
 Personal de infraestructura: Vista de Despliegue

Alcance

El presente documento brinda una visión general del sistema, mostrando sus
características con respecto a los principios arquitectónicos y abarcando los
siguientes temas:

 Representación de la arquitectura: Describe qué es la arquitectura de


software del Sistema y cómo se representa.

 Vista de Casos de uso: Presenta los casos de uso arquitectónicamente


representativos del sistema, con el fin de tener un panorama global de la
solución y detectar el impacto de dichas funcionalidades en la arquitectura.
 Vista Lógica: Describe las partes significativas de la arquitectura en términos
de su descomposición en subsistemas y paquetes.

 Vista de Despliegue: Describe una o más configuraciones hardware y de red


sobre las cuales se ejecuta el Software.

 Vista de Implementación: Describe la estructura general del modelo de


implementación, la descomposición del software en capas y subsistemas en
el modelo de implementación y los componentes más significativos de la
arquitectura.

Definiciones, Acrónimos, y Abreviaciones

OMS Aplicativo para el manejo de Productos


Y ordenes

Referencias
 Modelado final - RequerimientosKS-OMS
 Modelado final - InformacionProyectoKS

Visión General

El presente documento está estructurado de la siguiente manera: representación


arquitectónica, metas y restricciones de la arquitectura, presentación de las 4+1 vistas.

Representación arquitectónica
Las vistas se representarán utilizando los siguientes recursos:

• Vista de Casos de Uso.

Se representan las funcionalidades generales del sistema por medio de


diagramas de Casos de uso con la notación UML. La descripción detallada
de cada uno de los casos de uso no está en el alcance de este documento.
• Vista Lógica.

Se realiza el Modelo Conceptual de la plataforma, que permite comprender el


dominio del problema, Para tal efecto, se desarrolla un diagrama de las
diferentes capas y subsistemas lógicos que representan el universo del
sistema con notación UML.

• Vista de Implementación.

Se detalla la estructura que describe el modelo de implementación de la


aplicación, su composición y cada uno de sus componentes por medio del
Diagrama de Componentes con notación UML, describiendo los patrones y
frameworks involucrados en la arquitectura planteada.

• Vista de Despliegue

Se muestra la relación de la aplicación a desarrollar, con el hardware


requerido para el despliegue del sistema. Se utilizará el Diagrama de
Despliegue en notación UML.

• Vista de Procesos.

Se muestra el flujo de comunicación entre los componentes más


significativos del sistema. Se utilizará el Diagrama de Secuencia con notación
UML.
Vista Casos de Uso
ud Caso de Uso OMS V2

OMS

Consultas
Especiales

Seguridad

Usuario OMS

Administración

Actualizar Estado
Ordenes

Los casos de usos arquitectónicamente significativos son:

 Administración: es importante resaltar que el sistema OMS maneja múltiples


bases de datos (Productos, Órdenes y Clientes) y que cada una de ellas se
encuentra en un motor de bases de datos diferente. por este motivo es
necesario contar con mecanismos que le permitan acceder a estos recursos sin
disminuir su eficiencia.

 Consultas Especiales: Como parte de los requerimientos funcionales se tiene la


consulta de órdenes, productos y clientes, con características importantes como
el uso de comodines, rankings clasificaciones. Se debe tener en cuenta que
esta información se encuentra en múltiples bases de datos y requiere tener
procesos adicionales que aseguren la velocidad de respuesta.
sd SecuenciaConsulta

Usuario OMS Base Datos


Productos y
Clientes

SQL Productos (CRUD)

SQL Productos (CRUD)

Resultado Consulta

Resultado Consulta

 Seguridad: Permite la definición de roles y permisos para toda la aplicación,


integrados con el servidor LDAP, donde se encuentran los usuarios de la
compañía.

sd SecuenciaSeguridad

Usuario OMS ESB LDAP

Credenciales Usuario

Credenciales Usuario

Credenciales Usuario

ValidacionCredenciales

ValidacionCredenciales

ValidacionCredenciales

 Actualizar Estado Órdenes: requiere un alto esfuerzo de integración, ya que


debe llegar a los proveedores externos y actualizar el estado de las órdenes en
los sistemas internos.
sd ActualizarEstadoOrdenes

Usuario OMS Base Datos Sony RapidServ ice


Clientes y
Ordenes

actualizarEstadoOrden

ConsultarOrden

Datos de la Orden

procesoActualizacion

ActualizarEstado

confirmarEstado

ActualizarEstado

confirmarEstado

ValidarTransaccion

Nuevo Estado Orden


Vista Lógica

A continuación se describe las partes más significativas de la vista.

Visión general
cd OMS - Vista Logica

Presentacion

Pagina Pagina Clientes


Campañas Pagina Pagina Ordenes Login
Productos

Negocio

ManagerClientes
ManagerCampañas ManagerProductos ManagerOrdenes
+ Crear() : void autenticacion_autorizacion
+ Crear() : void + Modificar() : void + Crear() : void + Crear() : void
+ Modificar() : void + Eliminar() : void + Modificar() : void + Modificar() : void
+ Eliminar() : void + Consultar() : void + Eliminar() : void + Eliminar() : void
+ ActualizarCategoria() : void + Consultar() : void + Consultar() : void

Datos
Serv icios

Campañas Clientes Productos Ordenes


Ordenes LDAP

Paquetes de diseño Arquitectónicamente Significativos


A continuación se relacionan las agrupaciones lógicas más importantes de
diseño arquitectónico del sistema.

 Presentación
 Negocio
 Datos
 Servicios
Vista de Procesos
Con el fin de presentar la interacción entre los componentes más
representativos de la arquitectura, en esta sección se presenta la comunicación
entre procesos.

od OMS-Procesos

«thread»
Aplicacion

«process» «process»
«process»
Servidor Aplicaciones Servidor Base de Datos
Navegador

«process» «process»
Bus de Datos Empresarial Servidor L D A P

«thread»
Servicios Integracion

Diagrama de Procesos
Con esta vista se representan los siguientes procesos:
• Un proceso corriendo en el cliente que es un navegador que contiene la
interfaz de usuario.
• Un proceso en el servidor de aplicaciones, el cual esta a la espera de
peticiones por parte de un cliente y responde a estas peticiones
adecuadamente.
• Una vez el servidor de aplicaciones recibe la solicitud se invocan los
servicios ubicados en el bus de datos empresarial.
De acuerdo a las acciones ejecutadas por los clientes, se envían operaciones a
ser ejecutadas en los motores de bases de datos y/o en los sistemas externos
de mensajería
Vista Despliegue

A continuación se muestra un diagrama de despliegue, que muestra la


distribución de las componentes Hardware de la aplicación.

dd Despliegue

Serv idor de Aplicaciones


Serv idor BD Oracle
Nav egador {OS: Solaris}
{Server: Oracle Application Server 10g}
HTTP - HTTPS Base de Datos
{Browser: Chrome, firefox, IE}
TCP/IP Clientes Y
Ordenes
Aplicacion Web

TCP/IP Serv idor BD SQL Serv er

Base de Datos
Productos

TCP/IP

ESB

Serv icios

TCP/IP HTTP
HTTP LDAP

DHL Serv iEntrega Deprisa Serv idor de


directorio Activ o

Serv icio BD Directorio LDAP


Web

Características generales:
 Los componentes de la capa de presentación y Negocios corren dentro
del mismo servidor de aplicaciones.

 Todos los servicios de integración a otros sistemas están centralizados en


el Bus de datos empresarial que es el componente que maneja los
detalles de la comunicación con las empresas de mensajería, permitiendo
así que las capas superiores no se vean afectadas por cambios en estas
implementaciones.
 Cada servidor tiene un rol definido (Web, Base de datos, aplicación), que
permite hacer extensible y mantenible la infraestructura, sin afectar otras
capas de la aplicación.

Vista Implementación

A continuación se presentan las diferentes piezas físicas de la aplicación y su


posición en las diferentes capas lógicas definidas para el sistema.
cd OMS - Vista Implementacion

Presentacion

HTML
Controladores

Negocio

Clases Negocio Interfaces Acceso

Datos Serv icios

Entidades Proxy

Visión general

Las 4 capas que definen la arquitectura del sistema son: Presentación, Negocio,
Servicios y Datos.
Capa de Presentación:

Esta capa comprende las páginas HTML creadas para la administración de


clientes, ordenes, campañas y productos y las páginas de consultas especiales.

Capa de Negocio:

Incluye los componentes encargados de procesar los datos ingresados por el


usuario, en las diferentes opciones de administración y consultas y así mismo de
comunicarse con los servicios requeridos por la aplicación.

Capa de Servicios:

Contiene las interfaces que permiten acceder a los servicios en otros sistemas
como las empresas de mensajería.

Capa de Datos:

Incluye el modelo de entidades de la aplicación, que son las clases que deben
ser persistidas en las diferentes bases de datos legadas. Productos (SQL
Server) y Clientes-Ordenes (Oracle).
Vista de Datos
Tamaño y desempeño

Los siguientes son los supuestos que se manejaran con respecto al desempeño
de la aplicación:
 Los tiempos de respuesta de las consultas no deben sobrepasar los 5
segundos.
 La aplicación debe tener una disponibilidad del 99.99 %

Calidad

La arquitectura del software se diseño para ser independiente de la plataforma


del sistema, ofreciéndole así la capacidad de ser portable.
Adicionalmente la aplicación está diseñada por capas, de tal manera que las
capas más superficiales como la de interfaz no afecta la capa lógica. Cada capa
se comunica con la capa que esté directamente por debajo o sobre ella. No
existen saltos de acceso entre capas de manera tal que se mantenga una
eficiente comunicación entre ellas.
7. Vista de Datos
8. Tamaño y desempeño

Los siguientes son los supuestos que se manejaran con respecto al desempeño de la
aplicación:
· Los tiempos de respuesta de las consultas no deben sobrepasar los 5
segundos.
· La aplicación debe tener una disponibilidad del 99.99 %

9. Calidad

La arquitectura del software se diseño para ser independiente de la plataforma del


sistema, ofreciéndole así la capacidad de ser portable.
Adicionalmente la aplicación está diseñada por capas, de tal manera que las capas
más superficiales como la de interfaz no afecta la capa lógica. Cada capa se comunica
con la capa que esté directamente por debajo o sobre ella. No existen saltos de acceso
entre capas de manera tal que se mantenga una eficiente comunicación entre

7. caracterización de servicios

1. Identificación de los servicios objetivo:

Con el objetivo de identificar y escoger los principios y patrones SOA que

pueden aplicar al modelo de negocio ofrecido por la empresa KallSony’s es

conveniente basarse en los servicios definidos anteriormente. La figura 1

muestra los siguientes servicios separados por capas de negocio, aplicación y

tecnología.
Figura 1. Servicios definidos para el modelo de negocio de la empresa KallSony’s

1.1. Servicios en la capa de negocio


● Servicio de compra de teléfono
● Servicio de verificación
● Servicio de aprobación
● Servicio de compra
● Servicio de envíos
● Servicio de confirmación de compra

1.2. Servicios en la capa de aplicaciones


● Servicio de campañas
● Servicio de administración de clientes
● Servicio de actualización de inventario
● Servicio de registro de órdenes
● Servicio de conciliación

1.3. Servicio en la capa de tecnología


● Servicio de catálogo
● Servicio de clientes
● Servicio de ventas
● Servicio de contabilidad
● Servicio de envío de correos

2. Redefinición de servicios

De acuerdo a lo anterior es necesario realizar modificaciones en la definición y en


los nombres de algunos de estos servicios basándose en las recomendaciones y
buenas prácticas de la arquitectura orientada a servicios.

2.1. Servicios en la capa de negocio


● Servicio de solicitud de compra
● Servicio de verificación datos cliente
● Servicio de aprobación orden
● Servicio de compra a proveedores
● Servicio de envío de pedidos
● Servicio de confirmación de compra

2.2. Servicios en la capa de aplicaciones


● GestionarCatalogo
● GestionarCliente
● GestionarInventario
● RealizarOrdenePedido
● RealizarConciliacion
● EnviarNotificacionCorreos
Servicio en la capa de tecnología
● GestionarArchivoReclamos
● GestionarArchivoCorreos
● GestionarArchivoCatalogos
● GestionarArchivoConciliaciones

3. Aplicación de arquitectura orientada a servicios


Una vez se ha restructurado la definición de los servicios se procede a aplicar la
orientación a SOA.

3.1. Capa de servicios


En primer lugar se va a aplicar el patrón capa de servicios, separándolos en las
capas: capa de tarea, de entidad y utilitarios.
● Capa de servicios centrado en tarea: en esta capa se clasifican los servicios que
implementan lógica de negocio.

✓ GestionarCatalogo
✓ RealizarConciliacion
✓ EnviarNotificacionCorreos

● Capa de servicios centrado en entidad: En esta capa se clasifican los servicios


que representan entidades núcleo de la empresa.

✓ GestionarCliente
✓ GestionarInventario
✓ RealizarOrdenePedido

● Capa de servicios utilitarios: En esta capa se clasifican los servicios que son
transversales al modelo de negocio.

✓ GestionarArchivoReclamos
✓ GestionarArchivoCorreos
✓ GestionarArchivoCatalogos
✓ GestionarArchivoConciliaciones

1.1. Principios y patrones SOA

SERVICIO PATRONES PRINCIPIO ARQUITECT


S URA
❖ GestionarCliente Wrapper: Es necesario Reusabilida Servicio.
❖ RealizarConciliac aplicar este patrón debido a d del
ion que se necesita adaptar y servicio.
❖ RealizarOrdeneP transformar la información Bajo
edido que se obtiene de las acoplamien
aplicaciones: aplicación de to.
contabilidad construida en Servicio sin
COBOL, aplicación de estado.
manejo de clientes Composició
construida en Visual Basic, n de
aplicación de productos y servicios.
órdenes construida en JAVA
Enterprise. Esto con el
objetivo de poder consumirla
desde la aplicación “Tienda
virtual” que se construirá en
Asp .Net MVC 4.0.
❖ GestionarCatalog Centralización y Abstracción Composición
o redundancia del contrato: . .
❖ GestionarCliente Se propone manejar un único Sin estado. Servicios.
❖ GestionarInventa contrato base para todos los Descubrimi
rio consumidores de los ento.
❖ RealizarOrdeneP servicios (aplicación tienda Bajo
virtual) el cual enmarca las acoplamien
edido
políticas básicas que dichos to.
❖ RealizarConciliac consumidores deben cumplir.
ion También se propone hacer
❖ EnviarNotificacio redundancia de contratos
nCorreos dependiendo del consumidor
y del servicio a consumir. Por
ejemplo para el servicio de
clientes e inventarios se
propone un contrato con
políticas de seguridad como
cifrada y autenticación.
❖ RealizarConciliac Facade: Es necesario aplicar Reusabilida Servicio.
ion este patrón debido a que se d del
❖ EnviarNotificacio necesita consumir la servicio.
nCorreos información de otros Descubrimi
❖ RealizarOrdeneP servicios para poder seguir ento de
edido con la lógica de negocio que servicios.
se desea realizar. Por Composició
ejemplo: se necesita n de
consumir el servicio servicios.
contabilidad y de órdenes Abstracción
para poder realizar las .
conciliaciones; se necesita
consumir el servicio de
clientes y ventas para
realizar las notificaciones de
correo.
❖ EnviarNotificacio Agente de servicio: Se Reusabilida Inventario de
nCorreos plantea aplicar este patrón d. servicios.
para que permita garantizar Bajo Composición
que el envío de acoplamien .
notificaciones de correo se to.
realice siempre y cuando una
orden de pedido sea dada de
alta.
❖ RealizarConciliac Metadatos de mensajería: Servicios Composición
ion Se propone implementar este sin estado. .
❖ EnviarNotificacio patrón para hacer más fácil Bajo
nCorreos la comunicación entre los acoplamien
❖ RealizarOrdeneP servicios que se necesitan to.
edido consumir para hacer la
composición. Por ejemplo se
debe especificar como
metadatos el timeStamp, un
GUID de transacción, un
identificador de servicio.
❖ GestionarCliente Transformación de modelo Estandariza Inventario de
❖ RealizarConciliac de datos: Es necesario ción del servicio.
ion realizar la transformación de contrato. Composición
❖ RealizarOrdeneP los datos para poder Bajo . Servicio.
edido comunicar las aplicaciones acoplamien
de contabilidad, cliente y to.
productos con la aplicación
de tienda virtual.
❖ RealizarOrdeneP Encolamiento asíncrono: Estandariza Inventario de
edido Es necesario implementar ción. servicio.
❖ EnviarNotificacio este patrón debido a que es Bajo Composición
nCorreos muy costoso manejar acoplamien .
❖ GestionarArchivo múltiples transacciones y to.
Reclamos tareas asociadas a estos Servicio sin
servicios al mismo tiempo. estado
❖ GestionarArchivo
Por lo tanto se propone
Correos utilizar un sistema de
❖ GestionarArchivo encolamiento para manejar
Catalogos las tareas de notificación de
❖ GestionarArchivo correos donde la primera
Conciliaciones notificación es la de fecha
más antigua. Del mismo
modo todas las tareas
asociadas al manejo de
archivos se harán por esta
misma vía.
❖ GestionarCatalog Inventario de dominio: Se Estandariza Empresa.
o propone crear un inventario ción del Inventario de
❖ GestionarCliente de dominio. Esto con el contrato. servicios.
❖ GestionarInventa objetivo de implantar una Abstracción
rio filosofía de organización y .
❖ RealizarOrdeneP responsabilidad en la Composició
organización. n
edido
❖ RealizarConciliac
ion
❖ EnviarNotificacio
nCorreos
❖ GestionarArchivo
Reclamos
❖ GestionarArchivo
Correos
❖ GestionarArchivo
Catalogos
❖ GestionarArchivo
Conciliaciones

❖ GestionarCliente Abstracción de utilidad: Se Abstracción Inventario de


❖ GestionarInventa plantea implementar este . servicios.
rio patrón con el objetivo de Bajo Composición
❖ RealizarOrdeneP exponer a los consumidores acoplamien .
edido lo estrictamente necesario to. Servicios.
❖ RealizarConciliac para que dichos servicios Reusabilida
puedan ser consumidos y d.
ion
presten la funcionalidad que Composició
se requiere. La idea es no n.
revelar detalles de
implementación de los
servicios.
Capa de servicios Capa de servicios: Se Reusabilida Inventario de
centrado en tarea: plantea dividir los servicios d. servicios.
❖ GestionarCatalog en tres capas. Composició Servicios
o 1. Capa de servicios n.
❖ RealizarConciliac centrado en tarea: en
ion esta capa se clasifican los
❖ EnviarNotificacio servicios que
nCorreos implementan lógica de
negocio.
Capa de servicios 2. Capa de servicios
centrado en entidad: centrado en entidad: En
❖ GestionarCliente esta capa se clasifican los
❖ GestionarInventa servicios que representan
rio entidades núcleo de la
❖ RealizarOrdeneP empresa.
edido
3. Capa de servicios
utilitarios: En esta capa
Capa de servicios
se clasifican los servicios
utilitarios:
❖ GestionarArchivo que son transversales al
Reclamos modelo de negocio.
❖ GestionarArchivo
Correos
❖ GestionarArchivo
Catalogos
❖ GestionarArchivo
Conciliaciones

3.3. TradeOffs

PATRONES GANACIA PÉRDIDA


Wrapper ✓ Integración para ✓ Esfuerzo de
habilitar la integración.
interoperabilidad entre ✓ Afecta al
aplicaciones de desempeño.
diferentes tecnologías.
✓ Un único punto de
modificación si cambia
un requerimiento.
✓ Portabilidad.
Centralización y ✓ Un único punto de ✓ Gran esfuerzo de
redundancia del contrato acceso a las organización,
capacidades de los responsabilidad y
servicios. sincronización entre
✓ Estandarización de negocio y TI.
políticas, esquemas, ✓ Único punto de
formatos y protocolos. falla.
Facade ✓ Reutilización de ✓ Genera un punto de
capacidades asociadas acoplamiento fuerte.
a un mismo proceso de ✓ Único punto de
negocio coordinando fallo.
varios servicios de
negocio implicados en
dicho proceso.
✓ Abstracción de los
detalles de
implementación de los
servicios.
✓ Puede ser usado
como adaptador de
mensajes a los
servicios que gobierna.

Agente de servicio ✓ Permite establecer ✓ Delicada
condiciones para implementación debido
consumir capacidades a tareas de monitoreo y
de los servicios. fallas en la
✓ Permite ejecutar comunicación entre
tareas dinámicas servicios.
basadas en eventos.
✓ Reduce la
dependencia entre
servicios.
Metadatos de mensajería ✓ Estandarización y ✓ Esfuerzo entre las
facilidad en la áreas involucradas
comunicación entre para definir el
servicios. contenido de los
✓ Organización de la metadatos.
información.
Transformación de modelo ✓ Conversión entre ✓ Dificultad en la
de datos esquemas de datos definición de un
para habilitar la esquema de datos
interoperabilidad. común.

Encolamiento asíncrono ✓ Permite almacenar ✓ Manejo de la


la información para un capacidad de
posterior almacenamiento de las
procesamiento y así colas.
mantener la ✓ Garantizar la
disponibilidad de las persistencia de la
capacidades de los información.
servicios. ✓ Manejo de errores
en el guardado de la
información.
Inventario de dominio ✓ Organización de los
servicios de acuerdo a
las capacidades que
ofrece.
✓ Garantiza
estandarización y
gobierno de los
servicios, de tal modo
que involucra a las
áreas de negocio.
✓ Alta sincronización
entre el negocio y TI.
✓ Cambio cultural en
la organización.
Abstracción de utilidad ✓ Oculta el detalle de
implementación de los
servicios.
✓ Ofrece gran
reusabilidad aportando
al retorno de la
inversión.
✓ Aporta a la
composición de
servicios.
Capa de servicios ✓ Organización de ✓ Afecta al
servicios de acuerdo a desempeño.
sus capacidades. ✓ Sensible a
✓ Aporta al latencias.
descubrimiento de los
servicios.
✓ Aporta a la
composición.