Modelamiento de Arquitectura Empresarial

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

• 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.
Estímulo El tamaño máximo de cada página es de 60 kb y debe soportar

15 elementos.

Sistema

• 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.
Estímulo El portal debe responder a plataformas, moviles , de escritorio y

a tecnologias de navegador distintas.

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
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.
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.
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
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
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
Reclamos
Correos
Catalogos
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.
Correos
Catalogos
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
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
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.

Modelamiento de Arquitectura Empresarial

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Modelamiento de Arquitectura Empresarial

Enviado por

Direitos autorais:

Formatos disponíveis

ENTREGA FINAL MODELAMIENTO- EMPRESA KALLSONYS

GERMAN ALONSO SUAREZ.

PONTIFICIA UNIVERSIDAD JAVERIANA

Definición de la VISIÓN DE AE.

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

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

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

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

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

RESUMEN DEL NEGOCIO:

FUERZAS DEL MERCADO

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

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

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

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

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

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

- Legados construidos en COBOL

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

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

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

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

IDENTIFICACIÓN DE LOS INTERESADOS.

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

Figura 2. Estructura de gobierno actual KALLSONYS.

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

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

REQUERIMIENTOS DE ALTO NIVEL DE LOS INTERESADOS.

- Apalancar una estrategia de arquitectura empresarial que permita visualizar el

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

P B A) ESFUERZO MINIMO B) MANTENER

INTERESADO INVOLUCRADO EN: TIPO

1. JUNTA DIRECTIVA. ESTRATEGIA C

4. GERENTE TOMA DE DECISIONES C

5. GERENTE COMERCIAL ESTRATEGIA B

6. GERENTE RRHH ESTRATEGIA A

7. DIRECTORES AREA ESTRATEGIA A

DEFINICIONES DE FRAMEWORK DE ARQUITECTURA:

RIESGO SEVERIDAD MITIGACION

Selección de un alcance Alta Continua comunicación

Incumplimiento con las alta Seguimiento continuo del

Fuga de talento del alta Mantener la motivación

Perdida de la información alta Mantener repositorios

métrica Medición unidad

Estatus del proyecto Porcentaje de avance ejecutado contra

desempeño Actividades ejecutadas contra

Entrega de informes Artefactos entregados/ artefactos a

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

Dominio Arquitectura Negocio

Dominio Arquitectura Negocio

Dominio Arquitectura Tecnología

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

DOCUMENTOS BORRADORES DE ARQUITECTURA

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

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

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

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

Elementos del {Módulo de transacciones}