BABOKv2.0 English

DISEÑO ARQUITECTONICO
EMPRESARIAL
UNIDAD V:
Arquitectura Empresarial
Ms. JESSIKA MARQUEZ OPPE
2,008
Agenda
Definición de la Arquitectura Empresarial
Componentes de la Arquitectura Empresarial
Metodologías para diseñar Arquitectura
Empresarial
Adecuación de EUP a framework Zachman
Productos y herramientas de Arquitectura
Empresarial.
Desarrollo de Artefactos.
Identificación de Roles.
Arquitectura
Según el estándar ANSI/IEEE Std 1471-2000, define a la

arquitectura como una “organización fundamental de un
sistema, conformada por sus componentes, las relaciones
entre ellos y su ambiente y los principios que gobiernan
su diseño y evolución”.
Por lo tanto, una Arquitectura en un proyecto informático es

la descripción formal del sistema, definiendo los
componentes y bloques de construcción que lo conforman,
así como el método y modelo de distribución que tendrán
éstos dentro de la organización.
Arquitectura empresarial es un registro de modelos y de
documentos que se encuentran totalmente integrados a
los objetivos de las cuatro arquitecturas principales:
Negocio, Aplicaciones, Datos y Red.
La importancia de una solución de arquitectura
empresarial bien desarrollada permite a las
organizaciones responder rápida, eficaz y positivamente a
las oportunidades y desafíos presentados por los actuales
cambios de mercado, consolidaciones del sector y
avances tecnológicos.
Desarrollar una arquitectura empresarial proporciona un
proyecto organizativo que puede ayudar a mejorar la
calidad, eficacia y responsabilidad de todo el negocio.
Las arquitecturas empresariales son importantes ya que las

organizaciones necesitan adaptarse rápidamente a los cambios
de los requerimientos de los clientes y las metas de negocio. Esta
necesidad influye en toda la cadena de actividades de la empresa
desde los procesos del negocio hasta el soporte de tecnologías de
información (IT), además que el cambio en una arquitectura
puede influir en otras arquitecturas. [1]
Una arquitectura de Modelamiento empresarial describe
básicamente la estructura de la organización, un conjunto de
elementos y la relación entre ellos. Asimismo, tratan de explicar
la estructura de una empresa o una parte de ella como los
sistemas de información. Entre las arquitecturas se encuentran
las de referencia que permiten organizar los conocimientos de la
organización.
[1] Trends in Enterprise Architecture Research, 2007

• La arquitectura empresarial es el arma más importante

para mantener el orden de un sistema.
• Presión constante por expansiones de funcionalidad.
• Aumentan complejidad y disminuyen eficiencia
• Es necesario mantener la arquitectura actualizada y
pronta para el cambio
• Escenario
Dentro de las razones para elaborar una arquitectura

empresarial, se encuentran las siguientes[1]:
Alineamiento: Asegura alineamiento con la realidad de la
empresa.
Integración: Asegura que las reglas del negocio son consistentes,
información está estandarizada y la conectividad y
interoperabilidad está debidamente administrada a lo largo de
toda la organización.
Cambios: Facilita la administración de cambios a lo largo de toda
la organización.
Convergencia: Asegura que haya un portafolio de productos de
TI acorde con el modelo de tecnología de la empresa.
[1] GAO 2001
Beneficios de una Arquitectura Empresarial
El principal beneficio de contar con una buena

arquitectura empresarial es el de permitir a la
organización alcanzar el correcto balance entre
eficiencia tecnológica e innovación del negocio,
permitiendo que las unidades de negocio individuales
puedan innovar con seguridad en busca de ventaja
competitiva.
Al mismo tiempo, esta asegura la satisfacción de las
necesidades de la organización mediante una estrategia
de IT integrada, permitiendo la mayor sinergia posible a
través de la organización.
Modelamiento Empresarial
El modelamiento empresarial permite mejorar el performance de una
organización a través de la creación de modelos que utilizan una visión
holística, al manejar todos los componentes de una organización como
un todo integrado, unificando las áreas principales que definen la razón
de ser del negocio como son la gestión, negocio, procesos y tecnología.
El modelamiento empresarial es una herramienta, el cual se encuentra
desarrollado con un alto nivel de investigación, y que actualmente es un
tema de gran potencial investigativo.
Los modelos empresariales constituyen principalmente una base teórica
sobre los sistemas de información de una empresa, cuyo fin es brindar
una oportunidad para mejorar la competitividad de la industria frente a
los constantes cambios que se presentan y que toda empresa debe estar
al tanto para poder adaptar sus procesos con un impacto mínimo en las
variables de tiempo y costo.
Framework: un framework simplifica los conceptos de una

arquitectura, haciéndola fácil de entender, separando sus
procesos adecuadamente y ajustándose a un determinado tipo de
empresa lo cual los hace a algunos bastante específicos. La lista
de framework’s es bastante amplia, entre ellos encontramos al
Zachman, TOGAF, DoDAF, FEA, PERA, etc.
Así como frameworks, otro punto importante de las
arquitecturas empresariales son los ESTANDARES, con esto nos
queremos referir a las mejores prácticas que son fruto de un
consenso entre expertos en el tema. Modelos de estándares de
diseño son:
UML: Unified Modeling Language, que se usa para modelamiento
orientado a objetos.
Entity Relation diagrams (E/R)
BPMN: Business Process Modeling Notation: sirve para modelar
procesos del negocio.
SOA: Service Orientated Architectur, estándar que surgió a partir de la
creación de los Web Services.
Los frameworks dan la libertad a las empresas, en caso se desee aplicar
una arquitectura, yo pueda elegir deferentes tipos de estándares a
seguir, está elección estará basada en el skill de los trabajadores con el
estándar y la flexibilidad que brinde el framework para usar el estándar.
Usando una arquitectura empresarial un estándar puede ser analizado
para saber como, con la ayuda de este, se pueden agregar nuevas
funcionalidades a los sistemas sin que esto limite la flexibilidad de la
empresa cuando se desee agregar alguna adicional.
Metodologías para diseñar Arquitecturas Empresariales
1. Enterprise Unified Process (Extending The

RUP)
ARQUITECTURA EMPRESARIAL
1. Defining
architecture
requirements
workflow
details
2. Defining Candidate Architectures
Definir una Arquitectura Candidata puede ser tan abstracto

como la declaración de "empezar a exponer las aplicaciones
a un público más amplio de usuarios, posiblemente a través
de servicios web“.
Se puede presentar varios formatos, desde algo tan simple
como un párrafo que describe la idea de un simple
documento de posición a la descripción de una nueva
tecnología.
Dependiendo del alcance del candidato arquitectura, puede
que tenga que investigar más a fondo a través de línea de
investigación, la asistencia a conferencias o sesiones de
formación, grupos de discusión en línea, o hablando con
expertos en otras organizaciones que tienen experiencia en
las tecnologías.
Finalmente, se debe mostrar la arquitectura

seleccionada que realmente funciona y encaja en su
actual arquitectura de la empresa. Por supuesto cada
producto funciona perfectamente, en la literatura de
marketing, pero eso no quiere decir que funcione en la
empresa , se considera una situación de riesgo
mediante la adopción de una solución tecnológica que
no se está familiarizado con.
Además, tecnologías como. NET y J2EE son alguna de
las plataformas que debe adaptarse a la empresa. Es
necesario abordar detalles como:
¿Cuál (s) funcionará mejor para la empresa, ahora y en el

futuro?
¿Cómo se construye con las aplicaciones. NET integración con
aplicaciones heredadas y las fuentes de datos?
¿Cómo hará que . NET se despliegue mediante que apoyo?
¿Qué partes de. NET pueden utilizar las aplicaciones y las partes
que deben evitarse?
¿Cómo va la seguridad se aplicará en. NET?
Todas estas cuestiones, y más, deben ser investigados y
probados para trabajar dentro de su entorno. No es suficiente
decir simplemente que funcione, sino que debe demostrarse a
trabajar.
3. Refining
the
enterprise
architecture
workflow
details.
4. Defining Reference Architectures
Una arquitectura de referencia es un ejemplo de trabajo

diseñado y probado para su uso en un dominio particular,
junto con el apoyo artefactos a aplicar.
Las Arquitecturas de referencia ayudan a los equipos de
aplicación a reducir al mínimo esfuerzo los gastos de
apoyo, porque son aplicaciones en arquitectura estándar.
Arquitecturas de referencia no son modelos teóricos de
cómo podrían funcionar las cosas. Para ello existen
modelos o patrones de cómo hacer las cosas de trabajo.
Nada demuestra mejor que el código de trabajo que
pueden inspeccionar los equipos para ver la forma de
aplicarla.
4. Defining Reference Architectures
Una arquitectura de referencia pueden ser orientados

hacia una determinada tecnología o el dominio.
La arquitectura de referencia deberá documentarse de un
modo fácil de utilizar por los desarrolladores de
aplicaciones. Una forma de hacerlo es crear un estándar
de Arquitectura de Software RUP Documento (SAD).
Es importante tener presente, el desarrollo de la
documentación concisa y bien escrita.
5. Supporting Project Teams
ARQUITECTO
EMPRESARIAL
ARQUITECTOS DE ARQUITECTOS DE
SOFTWARE NEGOCIO
STAKEHOLDER
EMPRESARIAL
5. Supporting Project Teams
Foco en las personas y no la tecnología o las técnicas.

El plan debe ser sencillo.
El trabajo iterativa y gradual.

Compromiso con el equipo proyecto.
Construir antes de hablar de ello. Todo funciona en los
diagramas, pero puede fallar miserablemente en la
práctica.
Tener una vista panorámica.
Hacer arquitectura atractiva para sus clientes.
Services Oriented Maturity

SOM
Provee un framework que facilita la comunicación entre el personal de
TI y los usuarios de negocio.
Permite conocer la aplicabilidad y beneficios y beneficios de SOA en
la organización, mediante la adopción de 5 niveles de madurez.
Beneficios:
Los servicios Web. Envuelven la funcionalidad heredada y la exponen
hacia terceras partes:, clientes y partners de negocio.
Cómo empiezo a adoptar SOM:
Cambiar la cultura organizacional del equipo de desarrollo.
Mejor soporte tecnológico, transparencia en protocolos, SO,
conexiones punto a punto, etc.
Aprovechamiento y soporte de nuevas tecnologías.
Integración transparente, en términos reales Service Oriented
Integration.
Services Oriented Maturity
¿Porqué?
SPA (Services Paradigm Adoption):

•La orientación a servicios presenta un mundo ideal
con todos los recursos claramente particionados y
representados en términos de servicios.
•El Paradigma de Servicios debe ser adoptado por la
arquitectura empresarial para adecuarse a dicho
concepto.
•Resultados: flexibilidad, adaptabilidad y agilidad.
Hay que tener en cuenta que la Orientación a Servicios no es

una arquitectura en sí misma, sino un estilo arquitectural,
una guía o métodos de representar los recursos en forma de
servicios
¿Porqué?: SPA (Services Paradigm Adoption):
ARTEFACTOS:
Los siguientes artefactos sirven para acercarnos a la
necesidad de una arquitectura. Muestran el propósito de
implementar esta y como es que mejoraría la comunicación
dentro y fuera de la empresa.
DRS
Diagrama de Integración
Definición de Servicios
• Req.
Técnicos
• Req.
de Negocio
REQUERIMIENTOS DE NEGOCIO:
Ejemplo:
• El proceso de compras requiere que exista una interfaz vía web en el cual
el centro de costos correspondientes pueda ingresar su solicitud de
requisición indicando el producto que desea adquirir.
• El proceso de compras requiere que la requisición sea aprobada a través
del sistema y se envíe automáticamente al área solicitante que su
requisición fue aprobada o desaprobada por el proceso de Compras.
• El proceso de compras requiere realizar la comprobación del presupuesto
de cada centro de costos en base a su requisición, para aprobar y
automáticamente generar la cotización al proveedor.
• El proceso de compras para realizar las cotizaciones requiere ver los
productos disponibles del proveedor a través del sistema del proveedor.
REQUERIMIENTOS DE NEGOCIO:
Ejemplo:
•El proceso de compras requiere que una vez ingresada las cotizaciones
por los proveedores a través de la web, el sistema de compras elija el de
menor costo en cuanto a ítem determinados y si es un activo fijo el
empleado de compras pueda elegir a través de un clic y en ambos casos
generar automáticamente la solicitud de orden de compra (estado
pendiente) al proveedor.
•Se requiere que el sistema de compra reciba automáticamente la
aceptación de la orden de compra (pendiente) y se genera la orden de
compra con la información de la fecha en que nos va a enviar los
productos.
•Se requiere que el proceso de compras envíe automáticamente la orden
de compra al proceso de inventario y al proceso de Contabilidad.
REQUERIMIENTOS TECNICOS::
Ejemplo:
•Se requiere que el máximo de número de transacciones concurrentes
sea 200.
•Servidor para el administrador de archivos Windows Server 2000.
•Requiere seguridad informática.
•Los usuarios del proceso de compras tengan cuentas de usuario con
permisos repartidos según su rango, algunos contaran con permisos
de solo consulta y otros puedan aprobar o desaprobar las
requisiciones o ordenes de compra.
•Que el tiempo de respuesta nos sea mayor a 20 segundos.
•Para realizar una operación no se necesite hacer más de 2 click.
•Que cumpla la fiabilidad (La tolerancia de fallos y capacidad de
recuperación).
DIAGRAMA DE INTEGRACION:
Este artefacto permite ver las relación de los
módulos del proceso con los diferentes procesos
que tiene la entidad, identificando los servicios que
se brinda.
DIAGRAMA DE
INTEGRACION: 3 5
19
Ejemplo: 20
18
17
En el se ha identificado los 1
4
1
servicios que brinda cada 15
1
uno de módulos de los

distintos procesos que se 10
relacionan con el proceso de 7

6
16
compras. Junto a cada uno
de los paquetes se encuentra
2
el servicio que se ofrece y la 11
12
9
flecha dirigida apunta 14
13
indica el módulo del
proceso a quién se brindará 8
el servicio.
DEFINICION DE SERVICIOS:
Este artefacto muestra la lista de servicios
identificados en el diagrama de integración.
Cada uno de los servicios se encuentra numerado
según su identificación en el diagrama de
integración
LISTA DE SERVICIOS:
1. OrdendeCompraEjecutada
2. EnviarReportePago
3. VerEntregaProducto
4. ConsultarPresupuestoCentroCostos
5. DatosProveedor
6. ProveedorCandidato
7. OrdendeCompraProveedor
8. RequisiciónAprobada
9. ConfirmaciónOrdendeCompra
10. Quejas
LISTA DE SERVICIOS:
11. AtencionQueja
12. SolicitudCotización
13. Cotización
14. CatalogoenLinea
15. CronogramaRecepcionCompra
16. CotizaciónSeleccionada
17. DetalledeOrdendeCompra
18. ConsultarPresupuestoComprometido
19. VerAlmacenVirtual
20. CatálogoDeCuentas
DEFINICION DE LOS SERVICIOS:
Servicios que brinda la gestión de compras
(1) OrdendeCompraEjecutada:
Proceso que lo brinda: Gestión de ordenes de compra.
Procesos que lo utilizan: Gestión de Inventario y Gestión Contable y
Presupuestal.
Datos: Número, proveedor y monto total de la orden de compra aprobada por
el proveedor y pendiente de recepción y pago.
Uso: para el registro en los asientos y la verificación de la entrega.
(6) ProveedorCandidato:
Proceso que lo brinda: Gestión de cotizaciones.
Proceso que lo utiliza: Gestión de Control.
Datos: razón social, dirección, teléfono, ruc del proveedor sugerido a ser
evaluado.
Uso: para evaluar un proveedor sugerido por el proceso de compras.
Servicios que brinda la gestión de compras
(7) OrdendeCompraProveedor:
Proceso que lo brinda: Gestión de ordenes de compra.
Proceso que lo utiliza: Gestión de órdenes de compra del sistema del
proveedor.
Datos: número de orden de compra, detalle de orden de compra, fecha de
envío.
Uso: para que el proveedor atienda la orden de compra.
(8) RequisiciónAprobada:
Proceso que lo brinda: Gestión de requisiciones.
Proceso que lo utiliza: Gestión de cotizaciones.
Datos: número de requisición, centro de costos.
Uso: realizar la cotización de una requisición previamente aprobada.
………
Servicios que consume la gestión de compras
(2) EnviarReportePago:
Proceso que lo brinda: Gestión de Pagos
Proceso que lo utiliza: Gestión de Post-Compra
Datos: Monto de pago realizado de cierta orden de compra.
Uso: Actualizar el historial de compra con el estado del pago de la orden de
compra.
(3) VerEntregaProducto:
Proceso que lo brinda: Gestión de Inventario
Proceso que lo utiliza: Gestión de Post-Compra
Datos: Esta de la recepción de los productos de la orden de compra.
Uso: Actualizar el historial de compra con el estado de la recepción del
producto.
Servicios que consume la gestión de compras
(4) ConsultarPresupuestoCentroCostos:
Proceso que lo brinda: Gestión Contable y Presupuestal.
Proceso que lo utiliza: Gestión de Cotización.
Datos: Presupuesto en soles de cada uno de los centros de costos.
Uso: Seleccionar la mejor cotización deacuerdo al presupuesto de cada uno
de los centros de costo.
(5) DatosProveedor:
Proceso que lo brinda: Gestión de Control
Proceso que lo utiliza: Gestión de órdenes de compra.
Datos: identificador, razón social, ruc del proveedor.
Uso: Creación de una orden de compra de un proveedor autorizado por
contraloría.
……
SPA: Adoptar Paradigma de Servicios
¿Con Quién? ¿Qué?
SOE (Services Oriented Enterprise):
— SOE nos conduce a un cambio organizacional, nos

da la base para construir una arquitectura SOA.
— En esta disciplina de la arquitectura empresarial,

es importante establecer la interacción que existen
en los equipos de trabajos.
— Establecer una estructura para el diseño de la

arquitectura de servicios propuesta.
¿Con Quién? ¿Qué?: SOE (Services Oriented
Enterprise)
Artefactos:
— HOJAS DE TRABAJO SERVICIOS
— MALLA DE SERVICIOS
Enterprise)
HOJAS DE TRABAJO SERVICIOS
Se muestra la aplicación y el caso de uso que solicita

el servicio, y luego la aplicación y el caso de uso que
ofrece el servicio.
Esta Hoja de trabajo nos servirá para hallar la malla
relacional de servicios
Enterprise)
HOJAS DE TRABAJO SERVICIOS

Casos de Uso
Aplicación (Quien pide) Servicio Aplicación Servicio CU Servicio
Módulo de
Administración de Administración Gestión de Administración de
requesiciones de requisición 19. VerAlmacenVirtual Inventarios artículos
Modulo de Modulo de
Administracion de Administrar Administracion de Ver y Aprobar
Cotizacion Cotizacion 8.RequisiciónAprobada Requisicion requisicion
Modulo de Modulo de Gestión
Administracion de Seleccionar Contable y Administracion de
Cotizacion Cotizacion 4. ConsultarPresupuestoCentroCostos Presupuestal Presupuestos
Modulo de Administrar Modulo de Gestión
Admnistracion orden de 18. Contable y Administracion de
Ordenes de Compra Compra ConsultarPresupuestoComprometido Presupuestal Presupuestos
Modulo de Administrar
Administracion de Enviar y Recibir Sistema de Procesos Cotizacion -
Cotizacion Cotizacion 13. Cotización de abastecimiento Proveedores
Modulo de
Administracion de Administrar Sistema de Procesos Administrar
Cotizacion Cotizacion 14. CatalogoenLinea de abastecimiento Catalogo
Modulo de Administrar Modulo de
Admnistracion orden de Administracion de Seleccionar
Ordenes de Compra Compra 16.CotizacionSeleccionada Cotizacion Cotización
Enterprise)
MALLA RELACIONAL DE SERVICIOS

Este artefacto es realizado a partir de la hoja de trabajo
antes presentado en el se muestra un módulo del sistema en
cuestion, luego por cada caso de uso se muestra el servicio
que brinda y que módulos de distintas gestiones de la
empresa utilizan el servicio para propósitos propios de sus
gestiones.
A continuación se presenta un ejemplo con el módulo de
Administración de órdenes de compra. Se puede apreciar
que brinda cuatro servicios y que son consumidos por
distintos casos de uso
Enterprise)
MALLA RELACIONAL DE SERVICIOS

Casos de Uso
Cuenta de Servicio Aplicación (Quien pide)
Modulo de Gestión Contable y Modulo de Sistema de

Presupuestal Gestion de Procesos de
Inventario abastecimiento
Administración
Control de de ordenes de
Actualizar Administrar Ingresos y compra -
Aplicación Servicio CU Servicio Servicio Presupuesto Asientos salidas Proveedor
Administrar
Cronograma de
Recepcion de
Compras 15.CronogramaRecepcionCompras 0 0 1 0
17.DetalledeOrdendeCompra 0 0 1 0
Administrar
Modulo de
orden de
Administracion de
Compra 1.OrdendeCompraEjectuada 1 1 0 0
ordenes de compra
Enviar y Recibir
Orden de
Compra 7. OrdendeCompraProveedor 0 0 0 1
SOE: Empresa orientada a Servicios
¿Cómo?
SOA (Service Oriented Architecture):

La Arquitectura Orientada a Servicios está conformada
de componentes e interconexiones que refuerzan la
interoperabilidad y la transparencia de localización.
Trata sobre el desarrollo y construcción de sistemas

usando componentes de software heterogéneos
direccionables en red.
¿Cómo?
SOA (Service Oriented Architecture):

— SOA nos presenta la manera de hacer tangible esa
visión adoptada con el Paradigma de Orientación a
Servicios (SPA).
— Debemos dar prioridad a los objetivos de esta
visión arquitectural: Independencia de
Tecnologías, Independencia del Ciclo de Vida,
Débil Acoplamiento y en general cualquier
propiedad que se le pueda atribuir a los servicios
Componentes de SOA
Servicios: Entidades lógicas - Contratos

definidos por una o más interfaces públicas.
Service provider: Entidad de software que

implementa una especificación de servicio.
Service consumer : Entidad de software que

llama a un service provider. Tradicionalmente
se lo llama “cliente”. Puede ser una aplicación
final u otro servicio.
Service broker: Tipo específico de service

provider que puede pasar requerimientos
de servicios a otros service providers.
Modelo de desarrollo de SOA
¿Cómo?: SOA (Service Oriented Architecture):
La arquitectura empresarial tiene también definida

al SOA, que es una arquitectura de servicios entre
los procesos internos de la Empresa
Artefactos:
— CAPA DE SERVICIOS
— METAMODEL
— CONTRATOS
CAPA DE SERVICIOS
Muestra cada uno de los servicios que ofrecen los
procesos en cuestión. Así mismo muestra los servicios
que ofrecen los demás procesos y que son consumidos
por la gestión de compras.
Estos servicios son identificados a partir de la malla de
servicios.
CAPA DE SERVICIOS
GESTION DE COMPRAS
GESTION DE GESTION DE GESTION GESTION DE GESTION CONTABLE GESTION DE
GESTION DE GESTION DE
INVENTARIOS ORDENES DE DE POST- CONTROL Y PRESUPUESTAL PAGOS
REQUISICIONES COTIZACIONES
COMPRA COMPRA
SERVICIOS
EXTERNOS SolicituddeCotizacio OrdendeCompra
n Proveedor Quejas
SERVICIOS
CONSOLIDADORES CronogramaRec
epcionCompras
VerAlmacenVirtua CotizacionSeleccion OrdendeCompra EnviarReporte

l RequisicionAprobada ada Ejecutada DatosProveedor CatalogodeCuentas dePago
SERVICIOS LEGACY
VerEntregaProduc ProveedorCandidat DetalleOrdendeC ConsultarPresupuesto
to o ompraEjecutada Comprometido
ConsultarPresupuesto
CentrodeCostos
METAMODEL:
Muestra una vista integrada entre los servicios que
servirán para que otras áreas se comuniquen con
nosotros y nosotros podamos comunicarnos con otras
áreas.
Estos servicios se encuentran agrupados según la capa de
servicios antes descritos y así mismo se presenta como es
que cada una de nuestros procesos internos se relacionan
y cuales son los web services que brindarán cada una de
los servicios mencionados.
CONTRATOS:
Sirven para poseer una formalidad en la prestación y
obtención de servicios con otros procesos.
Ejemplo:
Servicio: OrdendeCompraEjecutada
Descripción: Es el servicio que se brinda a los Módulos de los
Procesos de Contabilidad, Cuentas por Pagar, y Contraloría.
Además también se brinda al módulos de Post-Compra
Ubicación de la interfaz:
WebServicesOrdenesdeCompra
Operaciones
Enviar la orden de compra que fue realizada
Nombre de la operación: EnviarDetalleOrdendeCompra

Responsabilidades: Enviar la descripción de la Orden de Compra y los datos del
proveedor al cual se le realizo dicha compra.
Clientes: Módulos de los procesos de Contabilidad, Cuentas por Pagar ,

Contraloría y al Modulo de post-Compra.
Entradas: Orden de Compra Atendido

Salidas: Detalle de la orden de Compra (Nombre de los productos ,
datos del Proveedor, Fecha, Precio, Total)
Excepciones: Si la orden de compra no fue ejecutada entonces se envia la

información de que la orden de compra no fue realizada.
(Estado de orden de compra)
Servicio: OrdendeCompraProveedor
Descripción: Es el servicio que se brinda al Sistema de

Proveedores.
Ubicación de la interfaz:
WebServicesOrdenesdeCompra
Operaciones
Enviar la orden de compra al proveedor para que este la
apruebe o no.
Nombre de la operación: EnviarOrdenCompraProveedor

Responsabilidades: Enviar la Orden de Compra al
proveedor seleccionado.
Clientes: Sistema de Proveedor

Entradas: Orden de Compra
Salidas: Descripción de los productos
solicitados para la compra.
Excepciones:
SOA: Arquitectura Orientada a Servicios
¿Con que?
SOC (Services Oriented Computing):

SOI (Services Oriented Integrated):
— La granularidad de un servicio puede variar y además éste
puede estar disponible desde una sola máquina o de forma
distribuida.
— Los Servicios Web proporcionan una forma eficiente de
representación del Paradigma inicial (SPA) por medio de
su representación Servicios Web XML son definidos en
términos de formatos y secuencias de mensajes (WSDL), su
interacción Protocolo de intercambio de SOAP mensajes
basado en XML (SOAP), su descubrimiento y registro (vía
Servicios de Directorio en Internet (UDDI)) e incluso su
reutilización (Coreografía de Servicios como BPEL)
¿Con que?
Servicios WEB:
Los Servicios Web consisten de una clase particular de
servicio, que es invocado usando la conjunción de cuatro
tecnologías para su implementación: HTTP (invocación),
SOAP: Protocolo de intercambio de SOAP mensajes
basado en XML/XML (mensaje), UDDI: Servicios de
Directorio en Internet (descubrimiento) y WSDL:
Servicios Web XML son definidos en términos de
formatos y secuencias de mensajes (descripción).
Un Servicio Web sólo especifica la forma en que el servicio

es invocado, no cómo es implementada la lógica del
servicio.
¿Con qué?
SOC (Services Oriented Computing):

SOI (Services Oriented Integrated):
Artefactos:
• Diagramas de despliegue
¿Con qué?: SOC (Services Oriented Computing) y
SOI (Services Oriented Integrated)
DIAGRAMA DE DESPLIEGUE
Muestra como es que debe estar dispuesto
físicamente los equipos de la entidad, para que
puedan soportar la arquitectura propuesta.
En el ejemplo, cada una de las cajas es un servidor,
los paquetes son los módulos de cada una de las
gestiones, los servicios son los ofrecidos por cada uno
de los procesos de compras y las conexiones implican
una conectividad. Dentro de la empresa la
conectividad es mediante una red LAN y con los
proveedores es a través de Internet y middleware.
DIAGRAMA
DE
DESPLIEGUE
DIAGRAMA
DE
DESPLIEGUE
¿Cuándo?
STP (Services Transition Plan):

— Generalmente la aplicación de los anteriores
conceptos requiere de un plan de adquisición de
los mismos.
— Deben estructurarse las distintas fases necesarias,
la transición entre cada una de ellas, los hitos
necesarios e incluso los planes de contingencia que
se consideren oportunos dependiendo de los
niveles de criticidad.
¿Cuando?
STP (Services Transition Plan):
Artefactos:
• Plan de Trabajo
• Plan de Migración
STP: Plan de Transición de Servicios
Tarea próxima sesión
Analizar (especificando definición y

componentes de cada uno de ellos) los
siguientes términos y detalle su diferencia:
1. Modelo Tecnológico
2. Plataforma Tecnológica
3. Arquitectura Empresarial
4. Modelamiento Empresarial
5. Plataforma Tecnológica
6. Estándares Tecnológicos para Arquitecturas
Empresariales.
Adecue la metodologia EUP a otros tipos de

framework ya estudiados en las sesiones
anteriores:
2. Enterprise Architecture Planning
Propone 3 arquitecturas: Arquitectura de datos,

arquitectura de aplicaciones y arquitectura de TI.
Previo a las arquitectura propone un Modelamiento
del Negocio, el cual se ha considerado como una
arquitectura de negocio para el proyecto.
EMPRESA
Arquitectura del Negocio
La arquitectura de negocio se divide en 2 partes centrales:

Identificación de los procesos de negocio
Descripción de la Organización
Arquitectura de Datos
Listado de entidades de información candidatas

(EAP) -> Descripción de entidades
Definición de entidades, atributos y relaciones (EAP) -
> Diagrama de Clases
Relación de las entidades con las funciones del
negocio (EAP) -> Entidades y Procesos de Negocio
Modelo de Dominio
Arquitectura de Aplicaciones
Del Negocio
Listado de aplicaciones candidatas (EAP)
Definición de aplicaciones (EAP)
Relación de aplicaciones con las funcionalidades
(EAP)
Arquitectura de Aplicaciones
Para las aplicaciones de los proveedores

Estándares y requisitos exigidos a las aplicaciones
Definición de servicios generales consumidos por las
aplicaciones
Modelo de Integración de Aplicaciones
Arquitectura de TI
Del Negocio
Identificación de Principios de tecnología a aplicar
(EAP)
Definición de Plataformas y Distribución (EAP)
Relación entre Plataformas de tecnología con
aplicaciones y funciones del negocio (EAP)
Arquitectura de TI
Para las aplicaciones de los proveedores

Modelo de Distribución
Modelo de Comunicación
Investigar otras Metodologías de Arquitectura

Empresarial.
Adecuación de EUP a framework Zachman
• En 1987, John Zachman, escribió: “Para guardar el

negocio de la desintegración, el concepto de una
arquitectura de los sistemas de información se está
convirtiendo en menos de una opción y más de una
necesidad.”
• Marco el inicio para el desarrollo de la Arquitectura
Empresarial.
• Utilizado por muchas organizaciones para visualizar y
comunicar su infraestructura de información actual y
futura.
• En vez de observar el proceso como serie de pasos, él la
organizó alrededor de los puntos de vista (perspectivas)
de los stakeholders.
Stakeholders en la Arquitectura Empresarial
• Alguien que ha emprendido hacer negocio en una

industria particular.
• Gente de negocios que gerencia una organización.
• Analista de sistemas que desean presentar el negocio de
una forma disciplinada.
• Diseñadores, que aplican tecnologías específicas para
solucionar los problemas del negocio.
• Desarrolladores de sistemas.
• El sistema en sí mismo.
Modelo de Zachman
Marco Conceptual para la Administración de los Sistemas de

Información (John Zachman,1992)
— Muestra como todo se relaciona con todo. Esta es una taxonomía con
30 celdas organizadas dentro de 5 filas y 6 columnas. Su función no
es remplazar otras técnicas, si no ver como estas calzan en todo el
esquema
— Alcance
— Modelo de la Empresa o Negocio
— Modelo del Sistema
— Modelo Tecnológico
— Componentes
Framework Zachman
Categorías de Información
Que. Los datos manipulados por una organización

Como. Funciones y procesos
Donde. Localizaciones
Cuando. Acontecimientos que accionan actividades
Quien. Gente y organizaciones implicadas
Porque. Motivaciones y apremios que determinan como el negocio
se comporta.
Zachman Framework
VA Enterprise DATA FUNCTI ON NETW ORK PEOPLE TI ME MOTI VATI ON Based on work by
Architecture What How Where Who When Why John A. Zachman
S COPE Things Im portant Processes Business Im portant Ev ents Significant Business Goals S COPE
(CONTEX TUAL) to the Business Perform ed locations Organizations to the Business and Strategy (CONTEX TUAL)
Planner Entity = Class of Function = Class of N ode = M ajor People = Major Time = M ajor Ends/Means = Planner
Business Thing Business Process Business Locations Organizations Business Event Major Business Goals
ENTERPRI S E Sem antic M odel Business Process Business Logistics Work Flow M odel M aster Schedule Business Plan ENTERPRI S E
MODEL M odel System MODEL
(CONCEPTU AL) (CONCEPTU AL)
Owner Ent = Business Entity Proc = Business Process N ode = Business Location People = Organization Unit Time = Business Event End = Business Objectiv e Owner
R el = Business Relationship I/O = Business Resources Link = Business Linkage Work = Work Product Cycle = Business Cycle Means = Business Strategy
S YS TEM MODEL Logical Data Application Distributed System Hum an Interface Processing Business Rule S YS TEM MODEL
(LOGI CAL) M odel Architecture Architecture Architecture Structure Model (LOGI CAL)
Designer Ent = Data Entity Proc = Application Function N ode = IS Function People = Role Time = System Event End = Structural Assertion Designer
R el = Data Relationship I/O = User Views Link = Line C haracteristics Work = Deliv erable Cycle = Processing Cycle Means = Action Assertion
TECHNOLO GY Physical Data System Technology Presentation Control Rule TECHNOLO GY
MODEL M odel Design Architecture Architecture Structure Design MODEL
(PHYSI CAL) (PHYSI CAL)
Builder Ent = Segm ent/Table Proc = Com puter Function N ode = Hardware/Softw are People = User Time = Ex ecute End = Condition Builder
R el = Pointer/Key I/O = Data Elem ents/Sets Link = Line Specifications Work = Screen Form at Cycle = C om ponent Cycle Means = Action
DETAI LED Data Program N etw ork Security Tim ing Rule DETAILED
REPRESENTATI ONS Definition Architecture Architecture Definition Design REPRES ENTATI ONS
(OUT-OF-CONTE XT) (OUT-OF-CONTE XT)
Sub-Contractor Ent = Field Proc = Language Statem ent N ode = Addresses People = Identity Time = Interrupt End = Sub-C ondition Sub-Contractor
R el = Address I/O = Control Block Link = Protocols Work = Job Cycle = M achine Cycle Means = Step
FUNCTIONI NG Data Function N etw ork Organization Schedule Strategy FUNCTI ONI NG
ENTERPRI S E ENTERPRI S E
Ent = Proc = N ode = People = Time = End =

R el = I/O = Link = Work = Cycle = Means =
DATA FUNCTI ON NETW ORK PEOPLE TI ME MOTI VATI ON
What How Where Who When Why
Framework Rules
Basic Model = Entities and Relationships
Rule 1: Relationship
Entity Entity
Columns have no order
Rule 2:
Each column has a simple, basic model
Contextual Contextual
Rule 3:
Conceptual Conceptual
Basic model of each column is unique
Logical Logical
Rule 4:
Physical Physical
Each row represents a distinct view
Rule 5: As Built As Built
Each cell is unique Functioning Functioning
Rule 6: What How Where Who When Why
Combining the cells in one row forms a

complete description from that view
Zachman Framework – Row 1
Scope/Planner’s View
Motivation/Why
Business goals, objectives and performance External Requirements and
measures related to each function Drivers
Business Function Modeling
Function/How
High-level business functions
Data/What
High-level data classes related to each
function What How Where Who When Why
People/Who 1 Contextual Contextual
Stakeholders related to each function

Conceptual Conceptual
Network/Where Logical Logical
VA locations related to each function

Physical Physical
Time/When As Built As Built
Cycles and events related to each

Functioning Functioning
function
Enterprise Model/Designer’s View
Motivation/Why
Policies, procedures and standards Business Process Models
for each process Business Function Allocation
Function/How Elimination of Function Overlap
Business processes and Ambiguity
Data/What
Business data
People/Who Contextual Contextual

VA roles and responsibilities in each
process 2 Conceptual Conceptual
Network/Where Logical Logical

VA locations related to each process
Physical Physical
Time/When As Built As Built

Events for each process and sequencing
of integration and process improvements Functioning Functioning

System Model/Designer’s View
Motivation/Why
VA policies, standards and procedures Logical Models
associated with a business rule model Project Management
Requirements Definition
Function/How
Logical representation of information
systems and their relationships
Data/What
Logical data models of data and data What How Where Who When Why
relationships underlying VA information
People/Who
Logical representation of access privileges Conceptual Conceptual
constrained by roles and responsibilities

3 Logical Logical
Network/Where
Logical representation of the distributed Physical Physical
system architecture for VA locations

As Built As Built
Time/When
Logical events and their triggered responses Functioning Functioning
constrained by business events and their responses What How Where Who When Why
Technology Model/Builder’s View
Motivation/Why
VA business rules constrained by Physical Models
information systems standards
Technology Management
Function/How Solution Definition and
Specifications of applications that operate Development
on particular technology platforms
Data/What
Database management system (DBMS) type
requirements constrained by logical data models
People/Who
Specification of access privileges to Conceptual Conceptual
specific platforms and technologies

Logical Logical
Network/Where
Specification of network devices and their 4 Physical Physical
relationships within physical boundaries

As Built As Built
Time/When
Specification of triggers to respond to system Functioning Functioning
events on specific platforms and technologies What How Where Who When Why
As Built/Integrator’s View
Motivation/Why As Built
VA business rules constrained by specific
technology standards Configuration Management
Function/How Deployment
Programs coded to operate on specific
technology platforms
Data/What
Data definitions constrained by physical
data models
People/Who
Access privileges coded to control access Conceptual Conceptual
to specific platforms and technologies

Logical Logical
Network/Where
Network devices configured to conform to Physical Physical
node specifications
5 As Built As Built
Time/When
Timing definitions coded to sequence Functioning Functioning
activities on specific platforms and technologies What How Where Who When Why
Functioning Enterprise/User’s View
Motivation/Why
Operating characteristics of specific Functioning Enterprise
technologies constrained by
standards Operations Management
Evaluation
Function/How
Functioning computer instructions
Data/What
Data values stored in actual databases
People/Who
VA personnel and key stakeholders Conceptual Conceptual
working within their roles and responsibilities

Logical Logical
Network/Where
Sending and receiving messages Physical Physical
Integrated Integrated
Time/When
Timing definitions operating to sequence 6 Functioning Functioning
activities What How Where Who When Why

VA Zachman
Framework Portal
Zachman Framework
Zachman Framework
Empresas:
•Entidad autónoma formada por un grupo de procesos de
negocio que trabajan en conjunto.
Por lo tanto
•Pueden existir empresas dentro de otras.
•Una unidad de negocio dentro de la entidad empresarial,
es como una empresa, si esta opera independientemente.
•La empresa se puede también considerar como una
“Empresa extendida”, el alcance del impacto de un esfuerzo
de la arquitectura de la empresa podría también incluir
correlaciones con las entidades externas. Por ejemplo:
proveedores, socios de negocio, y clientes.
Zachman Framework
Arquitectura:
• Define y describe la plataforma requerida por la empresa de

modo que pueda lograr sus objetivos y lograr su visión del
negocio.
• Puede ser definida como: Un grupo de principios, de
pautas, de políticas, de modelos, de estándares, y de procesos
que, alineados con los requisitos de la estrategia y de la
información de negocio.
• Conduciendo la selección, la creación y la puesta en práctica
de las soluciones que se alinean con la dirección futura del
negocio

BABOKv2.0 English

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

BABOKv2.0 English

Încărcat de

Drepturi de autor:

Formate disponibile

DISEÑO ARQUITECTONICO

Ms. JESSIKA MARQUEZ OPPE

Según el estándar ANSI/IEEE Std 1471-2000, define a la

Por lo tanto, una Arquitectura en un proyecto informático es

Las arquitecturas empresariales son importantes ya que las

[1] Trends in Enterprise Architecture Research, 2007

• La arquitectura empresarial es el arma más importante

Dentro de las razones para elaborar una arquitectura

El principal beneficio de contar con una buena

Framework: un framework simplifica los conceptos de una

1. Enterprise Unified Process (Extending The

Definir una Arquitectura Candidata puede ser tan abstracto

Finalmente, se debe mostrar la arquitectura

¿Cuál (s) funcionará mejor para la empresa, ahora y en el

Una arquitectura de referencia es un ejemplo de trabajo

Una arquitectura de referencia pueden ser orientados

Foco en las personas y no la tecnología o las técnicas.

El trabajo iterativa y gradual.

Services Oriented Maturity

SPA (Services Paradigm Adoption):

Hay que tener en cuenta que la Orientación a Servicios no es

uno de módulos de los

relacionan con el proceso de 7

SOE (Services Oriented Enterprise):

— SOE nos conduce a un cambio organizacional, nos

— En esta disciplina de la arquitectura empresarial,

— Establecer una estructura para el diseño de la

HOJAS DE TRABAJO SERVICIOS

Se muestra la aplicación y el caso de uso que solicita

HOJAS DE TRABAJO SERVICIOS

MALLA RELACIONAL DE SERVICIOS

MALLA RELACIONAL DE SERVICIOS

Modulo de Gestión Contable y Modulo de Sistema de

SOA (Service Oriented Architecture):

Trata sobre el desarrollo y construcción de sistemas

SOA (Service Oriented Architecture):

Servicios: Entidades lógicas - Contratos

Service provider: Entidad de software que

Service consumer : Entidad de software que

Service broker: Tipo específico de service

La arquitectura empresarial tiene también definida

VerAlmacenVirtua CotizacionSeleccion OrdendeCompra EnviarReporte

Nombre de la operación: EnviarDetalleOrdendeCompra

Clientes: Módulos de los procesos de Contabilidad, Cuentas por Pagar ,

Entradas: Orden de Compra Atendido

Excepciones: Si la orden de compra no fue ejecutada entonces se envia la

Descripción: Es el servicio que se brinda al Sistema de

Nombre de la operación: EnviarOrdenCompraProveedor

Clientes: Sistema de Proveedor

SOC (Services Oriented Computing):

Un Servicio Web sólo especifica la forma en que el servicio

SOC (Services Oriented Computing):

STP (Services Transition Plan):

STP (Services Transition Plan):

Analizar (especificando definición y

Adecue la metodologia EUP a otros tipos de

2. Enterprise Architecture Planning

Propone 3 arquitecturas: Arquitectura de datos,

Arquitectura del Negocio

La arquitectura de negocio se divide en 2 partes centrales:

Listado de entidades de información candidatas

Para las aplicaciones de los proveedores

Para las aplicaciones de los proveedores

Investigar otras Metodologías de Arquitectura