IDU20091026-27 SOAINT DSA v9 - Es

www.swassociatesint.
com
Construyendo la Arquitectura
de Servicios:
Modelización SOA
Introduccion
Independent Guidance for

SOAINT Services Architecture
Construyendo la Arquitectura de Servicios
Sesiones de Trabajo
Sesión Titulo
0 Agenda
1 Plan de Servicios (Services Portfolio Plan): Enterprise y Project Visión General
2 Politicas en el Plan de servicios
3 Modelización de Conceptos de Negocio (Business Concepts)
4 Modelización de Business Type (Modelo E/R)
5 Identificación de Dominios de Negocio (Business Domains)
6 Identificación del Nucleo de Servicios (Core Business Services)
7 Modelización e identificación de Business Processes Services
Encontrando
Servicios
8 Modelización e identificación de Capability Services
9 Identificación de Utility Services
10 Identificación de Underlying Services
11 Arquitectura de Implementación - Decidiendo Automation Units
12 Arquitectura de Despliegue- Decidiendo Distribución de Servicios
13 Modelización y Diseño orientados a la Flexibilidad Completando la
Arquitectura
14 Descripciones de los Servicios
2 www.swassociatesint.com
Audiencia y Objetivos
Destinado a
Arquitectos Al final de las sesiones los asistentes
Diseñadores de Soluciones Software deberían:
Jefes de Projecto en proyectos SOA Entender el propósito y el contenido del
Plan de Servicios y la Arquitectura de
Menos util para Servicios
Haber practicado con
Arquitectos de Infraestructura Técnica
Identificación de los Servicios del
Desarrolladores
Núcleo (Core Business Services)
Especialistas de Pruebas
Uso de plantillas para la
Operadores IT
descripción de los Servicios
Administradores IT
Ser capaz de participar en las
actividades de planificación de Servicios
de una organización.
Cual es el propósito del Plan de Servicios
Asegurar que los servicios que se provisionen soportaran:
Una arquitectura débilmente acoplada, de modo que los servicios sean

reemplazables y compartibles.
Integración de sistemas – incluyendo procesos de negocio
Reutilización e integración de los “legacy systems”
Uso de “commodity services” cuando sea apropiado
Compartir servicios cuando sea apropiado
Optimización de procesos e innovación …
Para promocionar el alineamiento y la coherencia entre IT y el Negocio
Porqué un Plan de Servicios
Para prevenir la anarquía de Servicios

Duplicar esfuerzos
La superposición y/o incoherencia de funciones
El uso de estándares diferentes haciendo mas complejo el mantenimiento de los Servicios
Para proporcionar una estructura por capas que asegure:

Compartición de Servicios para muchas soluciones y procesos de negocio
Visión de 360º de cada recurso de negocio
Procesamiento coherente, datos y reglas de negocio para los recursos de negocio
Selección de proveedores de servicios
Estandarización (capas inferiores de la arquitectura) y customización (capas superiores)
La Planificación de Servicios es un esfuerzo adicional al proyecto

Debe ser activado un Registro, a nivel organización, para registrar servicios, actuales y
planificados y su utilización por las soluciones.
Entre proyectos que sigan las mismas politicas (arquitecurales, estándares, niveles de calidad
de servicio-QoS) debería ser posible compartir y reutilizar servicios.
Que es el Plan de Servicios (Service Planning)
Software Associates ha desarrollado un proceso metodológico que:
Identifica el Portfolio de Servicios

La colección de servicios software requeridos
Diseña una Arquitectura de Servicios

Clasificados por tipos y organizados por capas
Abarcando la especificación para el despliegue
Define o adopta Políticas

Que gobernaran como ha de proceder la planificación y suministro de
servicios.
Emite un Plan de trabajo
El Plan de Servicios, por ámbito
Ambito Organización Ambito Proyecto
Un proceso dentro de la Arquitectura Un proceso dentro de una solución concreta

Empresarial (enterprise plan) que: (project plan) que:
Define las politicas que gobiernan como Selecciona las Políticas que gobiernan
se planifican y aprovisionan los servicios como se planifican y aprovisionan los
servicios, dentro del proyecto
Diseña una Arquitectura de Servicios a Se preve un ‘starter set’ inicial, que podría
nivel empresa: ser reiterativo
Es la colección de servicios software
necesaria para todo el ámbito de la Diseña una Arquitectura de Servicios para
empresa el Proyecto
Es la colección de servicios software que
usará el proyecto
Prepara el Plan conteniendo
La Arquitectura de Servicios Prepara el Plan conteniendo
El enfoque de la transición La Arquitectura de Servicios
Las Políticas Definidas El enfoque de la transición
Las Políticas Definidas
Es un Plan, no es Software!
Características del Plan de Servicios
Los Servicios del Nucleo (core business services) corresponden a un conjunto de

conceptos de negocio permanentes (recursos, entidades, …)
A continuación, identifica Servicios de arquitectura en otras capas que

corresponden a
Procesos de Negocio
Utilidades
Servicios proporcionados por sistemas existentes, paquetes, o servicios adquiridos
El Plan no identifica todas las operaciones

El foco es sobre los servicios correspondientes al Ambito definido
Se identifican operaciones candidatas y de prototipo
Operaciones definidas como necesarias para los proyectos
Un Enterprise Plan puede llegar a ser muy grande construcción incremental

Un Dominio de cada vez = múltiples Project Plan
De acuerdo a las prioridades de negocio
Plan de Servicios – Politicas
Tácticas
Estrategias generales que influyen en procesos y otras políticas
ARCHITECTURE
‘Triage’: agrupación y priorización
Políticas sobre Fuentes (Sourcing Policies)
Fuentes de aprovisionamiento preferidas para cada tipo de servicio
Políticas de Arquitectura
Estructuración en capas y reglas de dependencia entre servicios
Diseño de restricciones
Políticas Comerciales acuerdos de compra-venta con terceros
Políticas del Ciclo de Vida de los Servicios
Reglas a aplicar en los diferentes estados del ciclo de vida
Estándares por defecto a ser usados
Estándares de web services (WS-* standards), estándares del sector
Expectativas de calidad de los servicios (QoS)
Calidad esperada para cada dominio, servicio y operacion en particular
Contenido del Plan de Servicios
1. Introducción 2. Políticas 3. Expectativas 4. Estructura d 5.1 Arquitectura de 6. Programación

Inicios Tacticas y de Calidad Arquitectura Servicios para el del Desarrollo
Priorización Expectativas Diagrama de 5.2 Arquitectura
Dominio <Dom1> de Planificación de
Objetivos de Negocio
de Dominios Servicios
Progreso
para el entregas de
para SOA Fuentes y
Rendimiento 5.3 Arquitectura
Dominio <Dom2> de Servicios
Objetivos y Alcance Políticas Definiciones Especificación de
Servicios para el
Progreso
del Plan Comerciales Expectativas Dominios la Arquitectura Planificación
Dominio <Dom3>
Políticas del de Seguridad Especificación de del Aprovisio-
Audiencia para el Implementación de
Progreso
la Arquitectura
Plan Ciclo de Vida de la Arquitectura namiento
los Servicios Especificación
Implementación de de Planificación
Responsabilidades Despliegue de la
la Arquitectura
la Arquitectura del Desarrollo
Políticas de la Arquitectura
Antecedentes e Implementación de
Arquitectura Apendices Despliegue de la de la Solución
historia Aproximación para
la Arquitectura
Políticas de Descripciones de Servicios laArquitectura
Transición
Despliegue de
Aproximación la
para
Diseño Descripciones de Unidades de
Estándares la Arquitectura
Transición
Automatización
Enfoque de la
Arquitectura Tecnica Transición
El alcance del Plan de Servicios podría ser para toda la organización, pero desarrollado por dominios de negocio
o por soluciones, de acuerdo a prioridades preestablecidas
La atención se centra en los servicios y su alcance. Las operaciones tan sólo se identifican
Las operaciones se definen como necesarias por los desarrolladores de solución y a continuación se asignan a
un servicio adecuado
El Plan se actualizará para reflejar el estado después de cada proyecto
Con el tiempo, el Plan incluirá servicios adquiridos, así como los servicios internos
El Plan podrá ser mantenido en un catálogo de servicios, junto con las especificaciones, SLAs, etc.
www.swassociatesint.com
Contenido del Proyecto de Planificación
APENDICE A
1. Arquitectura de Especificación de Servicios
Descripciones de Servicios
Introducción
Servicio 1
Diagramas
Servicio 2
Discusión
Servicio 3
etc
2. Arquitectura de Implementación de Servicios APENDICE B
Introducción Descripciones de Unidades de
Diagramas Automatización
Discusión Automation Unit 1
Automation Unit 2
Automation Unit 3
3. Arquitectura de Despliegue de Servicios etc
Introducción
APENDICE C
Diagramas
Arquitectura Tecnica
Discusión
Diagramas
Discusion
4. Enfoque de la Transición APENDICE D

Introducción Políticas del Plan
Table de Accíones Principales Policy 1
Policy 2
Policy 3
etc
El Plan podría ser mantenido en un Repositorio, conjuntamente con

especificaciones, SLAs, etc.
Visiones de la Arquitectura de Servicios
Arquitectura de Especificación
(para desarrolladores de consumo)
Visión de Negocio
(para usuarios de negocio)
Visión de Infraestructura
(para usuarios tecnólogos)
Arquitectura de Despliegue
(para operaciones)
Arquitectura de Implementación
(para desarrolladores de servicios)
Las tres visiones de la Arquitectura de Servicios
ARQUITECTURA de ESPECIFICACION
Orders Service
Products Service
Accounts Receivable API
ARQUITECTURA de IMPLEMENTACION Orders

Accounts << quasiComponent >> Service Stock Stock
Receivable Ordering Movements Reordering
<< legacySystem >> Ops Component << component >>
Accounting Product
Package Accounts Payable Products Service Management
Operations
ARQUITECTURA de DESPLIEGUE
applicationServer Mainframe
EJB Container TP Monitor
Order Fulfillment <<SOAP over JMS>> Ordering Component
1..* 1
Stock Management Purchasing Component
Product Management Sales And Billing
Accounting Package
“Big Picture” del proceso SOA
Planificación
Requsistos Planificación de Mejoras
de Negocio
Consumir
Aprovisionamento
De la Solución
Arquitectura y Diseño Implementación
de la De la Solución
Solución
Arquitectura y Diseño Aprovisonmiento

SOA de Servicios
Proporcionar
Planificación de la Implementacion
Transición De Servicios
Diseño Arqu. de la Instalación de la

Plataforma Despliegue de la
Plataforma
Posibilitar
Solución/Servicio Solución/Servicio
Solución/Servicio
Operación /Gestión de la
Solución/Servicio
Gestión
Plan de Adopcion SOA

Infraestructura de Gobierno y Gestión
Visión del proceso de Planificación de Servicios
Acuerdo sobre el Ambito del Plan de Servicios
Modelos de Definir Políticas de Planificación y Aprovisionamiento

Negocio
Realizar acciones de Priorización (Triage)
Modelo de Decidir Ambito y Planificar Iteraciones

Dominios
Arquitectura de
Obtener Modelos Detallados de Negocio Especificación
Modelo E/R
detallado de Servicios
Identificar Core Business Services y Dependencias
Modelo de Descripciones
Refinar Políticas
Funciones Identificar Otros Servicios y Dependencias de Servicios
Modelo de Arquitectura de
Identificar Unidades de Automatización y Depen.
Procesos Implementación
de Servicios
Modelo de Diseñar Arquitectura de Despliegue de Servicios
Arquitectura de
Sistemas
Despliegue de
Definir el enfoque de la Transición
Servicios
Obtener la aprobación del Plan Incremental
Publicar la nueva Release del Plan de Servicios Plan de Servicios
Ambito del Plan de Servicios
Un Enterprise Plan cubre una organización completa

Esto puede variar si:
Se trata de una subdivisión autónoma
incluye actividades con organizaciones y partners
El punto clave es:

El Plan cruza departamentos, aplicaciones y proyectos
Cada proyecto trabaja con un “fragmento” del Plan (Services Portfolio Plan)
Alternativa: crear Planes de Proyectos por separado - (PSP) Project Service Plans
Incluyen arquitecturas de especificacion, implementacion y despliegue
Arquitectura en capas y servicios, derivadas de los modelos
Es un enfoque mas realista para algunas organizaciones, pero
Limita los beneficios de SOA – fomenta los silos de servicios
Puede ser dificil fusionar los PSP’s en un único Plan de Servicios
Ambitos de Planificación y Arquitectura
Nivel Ambito de la Arquitectura Ventajas Desventajas / Retos

Sector Varios participantes en una Interoperabilidad entre Tiempo y esfuerzo para
industia o ecosistema, p.ej.: partiipantes del sector alcanzar el consenso
B2B, cadena de suministro,
...
Empresa Toda la Organización o Coherencia a traves de la Enforcement. Consensus
división autónoma organización
LoB Linea de Negocio (LoB: Coherencia a traves de la Consistencia con otras LoBs
Line of Busines Linea de Negocio Reorganización de LoBs
Proyecto Solución para un proyecto Flexibilidad dentro del Falta de visión común,
proyecto. Solución Posterior racionalización del
autocontenida portfolio
Proveedor Funciones ofrecidas por Hace accesible dichas Inconsistencia con
de proveedor. Ej,: legacys, funciones ciomo servicios arquitectura de cosumidores
funciones paquetes sw, servicios (use only as Underlying
externalizados Services)
Enfoque de la Planificación de Servicios
Centralizado Federado
Todos los Servicios Los Servicios son parte
forman parte de un Plan Enterprise Service de un Plan General
Portfolio Plan
General (Enterprise Enterprise (ESPP) pero actúan
Services Portfolio Plan) Service Portfolio PSP PSP PSP independientemente
Plan como PSPs
PSP PSP
Descentralizado PSP Evolutivo
Enterprise
Los Servicios están en Project
Los PSPs son usados en
Service
Planes Independientes Service PSP los primeros niveles de
PSP Portfolio
Los Proyectos pueden Plan Plan madurez. Posteriormente
colaborar informalmente entre se fusionan/adaptan a un
PSP PSP Plan General (ESPP) en
sí o con el Plan General
niveles superiores de
madurez.
Los Servicios son organizados en Capas y Dominios
Desarrollo de Control de Solution Layer

Pedidos Productos Stocks (presentación y dialogo)
Sales & Billing
Servicio Capability Services

Cumplimentación Servicio Gestión
(capa de orquestación)
de Stocks
Inventory
de Pedidos
Servicio Movimientos de Stock

Pedidos Servicio Core Business
Productos Compras de Stocks Services
Servicio (Capa “backbone”)
Clientes
Conversor de Moneda Utility Services

(Capa Alta Reutilización)
Formateador de Direcciones
Underlying Services
Cuantas a Pagar Compras (no fácil de desarrollar)
(desde el sistema de Contabilidad) (de un componente genérico)
Dominios
Particiones lógicas de una empresa consistentes en un conjunto de recursos

de negocio, mas los procesos de negocio que actúan sobre dichos recursos.
Ejemplo:
MANUFACTURING
DISTRIBUTION
SUPPLY
ASSETS
MARKETING FACILITIES
CUSTOMERS
FINANCE
HUMAN RESOURCES
Resources Business Processes

Empleado Contratación
Puesto de Trabajo Fidelización de Empleados
Departamento Cambios Organizativos
Fondo de Pensiones Gestión del Fondo de Pensiones
La identificación de Servicios se lleva a cabo partir de Modelos
de Negocio y de los Sistemas Existentes
ACTIVITY MODEL
Manage
BUSINESS TYPE MODEL
Lift ROLE CONTRACTING
Execution PIECE
COMMERCIAL
Load Move
BILL OF
Conveyance Conveyance LADING
SHIPMENT
UNIT RS STOP EVENT
Process Process replaces
Cargo For
Shipment
Load
Conveyance
Shipment at
Transhipment
Incheck
Passengers DOMAINS BASIC
LOCATION
& Cargo TRANSPORTATION SHIPMENT

Point UNIT UNIT
Conveyance
Generate Fixed
Shipment SUPPY Airports, Seaports, GELOC,

LATLON . . .
Documents SCHEDULING & BASIC Voyage Air
Mission
UNIT
TRACKING Point
SCHEDULING &
DISTRIBUTION
TRACKING
SUPPLY SHIPMENT UNIT
SHIPMENT UNIT REQUISITION
MATERIAL
ITEM
CONTRACTING CUSTOMERS FACILITIES ORGANIZATION

UNIT SUPPLY
FINANCE REQUISITION
RESOURCES DETAILS
PROCESS SERVICES
Process Cargo
Load Conveyance
CURRENT SYSTEM MODEL
CORE BUSINESS SERVICES
Transportation Unit
Requisition
UNDERLYING SERVICES INTERFACE METADATA REPOSITORY

TRANSFORMATION
SCHEMA SCHEMA
LOGICAL DATA MODEL

ABC 123
XYZ FGH DESIGN LOGISTICS MATERIAL
SSSS REQUISITION ITEM
GL GOVERNANCE
CRM
ERP PLM
REQUISITION
DETAILS
UTILITY SERVICES
Rules Engine Reference Data Note: All data shown is for illustration purposes only
Introducción al Plan de Servicios. Resumen
Los servicios se identifican desde los Dando lugar a la Arquitectura de Servicios

modelos de negocio que se desarrolla en tres niveles, o tres
Customer Branch Open Account
sub-arquitecturas
Account Employee Orders Service
Especification
Process Supply
Transaction Statement
Products Service
Accounts Receivable API
Close Account
Implementation
Orders
Los Servicios son organizados en capas Ordering
Service Stock Stock
Component Movements Reordering
Solution Sales
Product
System Management
Products
Service
Process Orders Process Service
Deployment
Orders Service
Core applicationServer Mainframe
Products Service
EJB Container TP Monitor
Order Fulfillment <<SOAP over JMS>> Ordering Comp
Utilities Stock Manag’t Purchasing Co
Product Manag’t Sales And Bill’g
Accounting Pk.
Underlying Accounts Receivable
22
de Servicios:
Modelización SOA
Definición de Políticas para la Planificación y

Aprovisionamiento de Servicios

Concepto y significado de Politica
Las Políticas del Plan de Servicios

dirigen y restringen la planificación y el
aprovisionamiento de Servicios
Idealmente, las Políticas deberían estar

decididas antes de que comience la
Planificación, pero en realidad se
necesitan dos o tres iteraciones para
completarlas y estabililizarlas.
La definición de Políticas es importante

para la consistencia general del Plan.
Significan “Una estrategia o directiva definida independientemente que regula como

trabajar y gobierna la planificación y el aprovisonamiento de servicios”.
Algunas políticas son obligatorias, otras son solo recomendaciones.
Usualente están expresadas en forma de texto (narrativo) que deja claro si es obligatorio
o recomendado.
Ejemplo de Política y propiedades
Propiedad Valor
Nombre de Política (unico) #135 Registro de movimientos dinerarios
Tipo de Política Arquitectura
Obligatoriedad Obligatorio
Autoridad para Anulación Director Financiero
Cumplimiento Verificado en la revisión de la especificacion. Verificado contra el procedimiento de
certificación.
Hay un plan para añadir un control al catálogo de servicios, el cual alcanza la ‘bandera
roja’ (red flag) cuando el servicio el servicio tiene acceso a la cuenta interna y no procede
de un Servicio de Auditoría
Fecha o Evento de Comienzo Immediatamente
Fecha o Evento de Final Indefinido
Autoridad CIO
Contexto(s) Sin restricciones
A implementar en Especificación del Servicio, Automation Unit
Objetivos Prevencion de fraudes internos. Detección de movimientos irregulares de dinero, ya sean
accidentales o deliberados.
Relación con otras Políticas Reemplaza a la Política #035
Lenguaje Narrativo
Terminos Clave - -
Acción Cada movimiento superior a 1.000 euros a una cuenta interna debe estar conectado con la
siguiente información: número de cuenta, referencia, fecha, hora, cantidad, ID de usuario
originario, dispositivo originario.
Plan de Servicios – Politicas
Tácticas
Estrategias generales que influyen en procesos y otras políticas
ARCHITECTURE
‘Triage’: agrupación y priorización
Políticas sobre Fuentes (Sourcing Policies)
Fuentes de aprovisionamiento preferidas para cada tipo de servicio
Políticas de Arquitectura
Estructuración en capas y reglas de dependencia entre servicios
Diseño de restricciones
Políticas Comerciales acuerdos de compra-venta con terceros
Reglas a aplicar en los diferentes estados del ciclo de vida
Estándares por defecto a ser usados
Estándares de web services (WS-* standards), estándares del sector
Expectativas de calidad de los servicios (QoS)
Calidad esperada para cada dominio, servicio y operacion en particular
Politicas: Tácticas
Tácticas de consumo de Servicios Tácticas de priorización (Triage)
Tácticas de abastecimiento de Servicios Prácticas de desarrollo para SOA
Tácticas de Planificación de Servicios Organización de desarrollo para SOA
Secuencia de adquisición de Servicios Tecnología
Fuentes preferidas de Servicios Diseño de secuencias ESB
Politicas: Selección de Fuentes
Diferentes métodos de adquirir un Servicio

Pre-existente, disponible comercialmente ‘comprar’
Pre-existente, adquiridos en paquete
Pre-existente ofrecida por partners ‘prestamo’

Construida ‘ad hoc’ por un partner socio
Adquirida ensamblando Servicios existentes

Funciones de sistemas Legacy - wrapping ‘en base a’
Componentes Software – adaptado como servicio
Adoptar especificaciones de la industria - outsourcing

Especificaciones propias, construcción externa ‘construidos’
Especificaciones y cpsntrucción propia
DIFFERENTIATING SERVICES Cada servicio es clasificado por su nivel de diferenciación
Innovador
Servicios originales de la organización, que se espera que den ventajas competitivas en un
futuro
Sujetos a continuos cambios y mejoras
Generalmente para apoyo a nuevos productos, mercados, canales, etc
Especialidad
Sercicios que la organización realiza de forma competitiva, o unica, que la diferencia y
contribuyen a elevar el precio de la acción
Relativamente estables pero precisan de control y capacidad de cambio
No adecuado el uso de paquetes, aunque el desarrollo podria se externalizado
Estandarizado
NON-DIFFERENTIATING SERVICES
Servicios no especializados que la organización puede llevar a cabo de manera tan eficiente
como sus competidores, pero no mejor.
Objetivo: normalización de estos servicios en la Organización. No interesa subcontratar, ya que
sigue siendo muy conveniente el control interno.
Podrían estar disponible en paquetes.
Commodity
Servicios bien conocidos por la organización que esta puede llevar a cabo de manera tan
eficiente como sus competidores, pero no mejor.
Posibilidad de externalización sin detrimento del negocio
Los proveedores probablemente pueden realizarlo por un menor costo o de manera más
eficiente
Políticas Comerciales
Consumo de Servicios por partners o terceros

Reunir una lista de ‘proveedores estratégicos’ de servicios: Libro Blanco, ...
Definir reglas para el uso de los servicios gratuitos
Definir las reglas para el uso de los servicios de pago
Ej.: Que mecanismos de tarificación son aceptables
Suministro de Servicios a partners o a terceros

Suministro de servicios gratuitos
Permitidos? A quien? Terminos y condiciones?
Venta de Servicoos Software
Mecanismos de cargo– subscripcion? alquiler?
Alojamiento de Servicios a terceros
Normativas para Acuerdos de Nivel de Servicio (Service Level Agreements)
Politicas del Ciclo de Vida de Servicios
Planificado
Especificado En todas las etapas de planificación de servicios,

el desarrollo y la producción deben estar bien
gestionadas y coordinadas
Siendo Aprovisionado
Los procedimientos deben ser diseñados, a fin

Aprovisionado de tener un servicio seguro y eficiente a través
de su ciclo de vida
Certificado
Los planificadores del servicio del ciclo de vida
definen las políticas y los procedimientos que
Publicado deben cumplir con estas
Operacional Los planificadores lanzan proyectos para la

creación de estos procedimientos del ciclo de
vida
Retirado
Archivado
Politicas de Certificación
Los principios de la Certificación, normas, limitaciones y directrices han de ser

definidos por los planificadores
Los servicios que se desplieguen como parte del portfolio de servicios deberían ser
"certificados" por los proveedores de servicios
Por ejemplo: requiere certificación

Los resultados de Pruebas de Servicios
La ejecución de una operación
La entrega de documentación y si es completa y exacta
La certificación se aplica a todos los servicios, ya sean externos de terceros, o
construidos o desplegados internamente.
Los procedimientos de certificación debe ser revisados, para que se ajusten a las
políticas correspondientes
Publicación y Políticas de Gestión de Activos
Los servicios desplegados como parte del Portfolio, deben ser publicados en un
registro o catálogo
UDDI (Universal Description Discovery and Integration) es el estándar para el registro:
especialmente para servicios disponibles externamente.
Los principios, reglas y lineas maestras son definidas en la Política

Estándares de catalogación y herramientas utilizadas para soportar esas políticas
Por ejemplo, el Catálogo de Servicios debería contener:
Visión general de todos los servicios por dominio
Publicidad de alto nivel orientada a negocio de cada servicio
Propiedades del servicio
Especificación Detallada de cada servicio
Acuerdos sobre la Calidad de Servicio
y podría contener:
Ejemplo de utilización
Resultados de pruebas
SLA (Services Level Agreement: Acuerdos de Nivel de Servicios)
La Unidades de Automatización y especificaciones de Servicios son activos

valorables de la organización
Necesitan ser gestionados por un Sistema de Gestión de Activos
Considerese la adopción y compra de una herramienta para tal
Otras Politicas del Ciclo de Vida
Políticas de Control de Cambios (CC)

Procedimientos necesarios para gestionar adecuadamente los arreglos y la
ampliación de los servicios en producción
La sección de Políticas del Plan define reglas generales y requerimientos que
deben ser cubiertos por los procedimientos de gestión de cambios
La Políticas CC pueden cubrir las variaciones en el desarrollo del sistema
En que situaciones son permitidas
Que técnicas deberían (o no) utilizadas para la elaboración de variantes del sistema
Políticas de Operación
Requisitos de Alto Nivel para la Monitorización y Gestión de los Servicios
Requisitos de Alto Nivel para la Operación en Producción
Políticas de Aprobación del Plan del Portfolio

P.Ej.: “cada nueva release debe estar autorizada y firmada por el Sponsor SOA,
el Propietario del Dominio y el Director de IT
Políticas de Aprobación de la Especificación de Servicios

P.Ej.: “cada nueva release de la Especificación debe estar autorizada y firmada
por el Propietario del Dominio y el Gerente de Planificación del Portfolio
Decidir Estándares por Defecto
La idea es:
Definir un conjunto de estándares por defecto que puedan ser razonablemente
aplicados a todos los servicios del Portfolio
Puede haber adiciones y/o variaciones por cada dominio, servicio u operación
específica
Los planificadores han de considerar estas categorias de estándares:

Protocolos Web Servicea de OASIS y W3C, incluyendo SOAP, WSDL, UDDI, y
perfiles de interoperabilidad WS-I
Enlace con los diseñadores de plataforma SOA
Estándares Generalizados de la Industria como por ejemplo ebSOA
Patrones generalizados de eBusiness que puedan ser potencialmente
plantillas para servicios de utilidades y procesos comunes
Estándares de la Industria Vertical como por ejemplo RosettaNET
Diccionario de Negocio
Modelos de procesos
Modelos de fabricantes de Paquetes
P.Ej.: SAP’s Enterprise Service Architecture
Estándares por Defecto -- Ejemplo
Ambito de Estándares: Enterprise-Wide

Dominio especifico de Servicios
que tendría los estándares
Release o
Estándares version Observaciones
Internos
Manual de estándares SOA 2.0 Los Servicios deben utilizar la nomenclatura estándar de la
compañía y el numero de release
La Especificación y cambios de Servicios, deben ser aprobados
por un miembro del equipo SPP y los propietarios del Dominio
Técnicos
WS-I basic profile 1.1 2nd Edition Los servicios internos deben cumplir con el perfil básico WS-I 1,1
SOAP 1.1 Los servicios de terceros deberan ser accesibles utilizando SOAP
bajo HTTP
WS-Coordination Las operaciones de actualización de que deben agruparse en una
transacción deben ajustarse a WS-Coordination
Industria
UBL 1.0 El ciclo pedidos-facturación adoptará UBL1.0 (OASIS Standard)
Regulatorios Ej.: regulaciones del Gobierno y/o de la Industria
Ninguna
Expectativas por defecto en la Calidad de los Servicios
La idea es:
Definir un conjunto de expectativas de calidad por defecto que pueda ser
aplicado a todos los servicios del Portfolio
Los proveedores deberan autorizar el acuerdo en estas espectativas
Los planificadores deberan definir objetivos comunes de calidad para el largo

plazo
No sobre demanda
Sólo un conjunto esencial de requerimientos
Categorias de Calidad
Acuerdos en un conjunto de Categorias de Calidad

Por ejemplo
Rendimiento Seguridad
Disponibilidad Autenticación
Fiabilidad Autorización
Rendimiento Privacidad
Tiempo de respuesta Integritdad del Mensaje
No-repudio
Incluir varios niveles apropiados para cada categoría

Por ejemplo:
Gold / Silver / Bronze niveles de rendiemiento
Red / Amber / Yellow niveles de seguridad
Los Planificadores (o arquitectos de la plataforma SOA) han de preparar
definiciones de cada nivel y categoría
Representantes del Negocio deberían revisar esta propuesta
Expectativas de Calidad por defecto – Rendimiento
Ambito Expectativas Calidad Empresa | <Nombre de Dominio>

Rendimiento Definición del Nivel
Disponibilidad
-Gold 24 x 7; máx. total 1 hora de inactividad al mes
-Silver 24 x 7; máx. 1 hora de inactividad al mes en jornadas de trabajo, 1 hora de inactividad al día
fuera de jornada de trabajo
-Bronze 24 x 7; máx. 1 hora de inactividad al mes en jornadas de trabajo, 2 horas de inactividad al día
fuera de jornada de trabajo
Fiabilidad
-Gold Una Operación sólo puede fallar 1 vez de cada 100.000
-Silver Una Operación sólo puede fallar 1 vez de cada 10,000
-Bronze Una Operación sólo puede fallar 1 vez de cada 1,000
Rendimiento
-Gold Deben procesarse picos de 100 solicitudes/segundo, con tiempos respuesta SILVER o mejor
-Silver Deben procesarse picos de 100 solicitudes/minuto, con tiempos respuesta SILVER o mejor
-Bronze Deben procesarse picos de 100 solicitudes/hora, con tiempos respuesta BRONZE o mejor
Tiempos de Etc.
Respuesta
Expectativas de Calidad por defecto – Seguridad
Scope of Quality Expectation: Enterprise | <Service Domain Name>

Seguridad Definición del Nivel
Autenticación
- Red El Solicitante debe autenticarse mediante certificado digital aprobado por la autoridad
- Amber Se debe validar identificador de usuario y contraseña
- Yellow No se requiere autenticación
Integridad del Mensaje
- Red Deben ser utilizados protocolos WS-Reliable Messaging, o cuando el transporte es
MOM la garantia de la entrega de mensajes y de orden de procesamiento.
- Amber Se podrá utilizar Internet como mecanismo de transporte
- Yellow La entrega de mensajes, secuencia e integridad no están garantizados
Privacy
- Red Se deben cifrar todos los mensajes usando la encriptación 128 byte
Debe utilizar mecanismos de transporte seguro SSL, ya sea privado o red segura
- Amber Debe utilizar mensajes cifrados
- Yellow No se necesita encriptación
Authorization (Permisos de acceso), etc
Non-repudiation Etc.
Cuando se necesitan Políticas de Planificación
Tipo de Politica Fase en que se necesita
Triage Antes de comienzar la Planificación de Servicios

Tácticas Antes de comienzar la Planificación de Servicios
De fuente de Antes de comienzar el Aprovisionamiento de Servicios a gran escala

aprovisionamiento
Comerciales Antes de consumir servicios ofrecidos por terceros
De diseño de Servicios Antes de comienzar el Aprovisionamiento de Servicios individuales
Cumplimiento de Antes de comienzar el Aprovisionamiento de Servicios individuales

estándares Antes incluso, si debe basarse en modelos estándar de la industria
Del Ciclo de Vida de los Políticas y procedimientos basados en estas políticas pueden ser
Servicios desarrolladas en paralelo con primeros proyectos de aprovisionamiento
De Expectativas de Antes de que Servicios individuales sean provisionados
Calidad
De Arquitectura Antes o como primera colección de servicios identificados
Contenido del Plan de Servicios

Progreso
para el entregas de
para SOA Fuentes y
Servicios para el
Progreso
Dominio <Dom3>
Progreso
la Arquitectura
la Arquitectura
la Arquitectura
Transición
Despliegue de
Aproximación la
para
Transición
Automatización
Enfoque de la
Resumen
Las Políticas aportan al Plan de Servicios:

Decisiones transparentes
Cumplimiento de estándares y calidad del servicio
Alineamiento con objetivos de negocio y expectativas de gestión
Base para un buen gobierno
En esta sesion se han visto:

Tácticas
Fuentes de Aprovisionamiento (diferentes vias de adquirir un servicio)
Políticas Comerciales
Estandares por Defecto
Expectativas de Clidad por Defecto
Triage, priorización
de Servicios:
Modelización SOA
Ejercicio
Decisión de Politicas para la
Planificación y Aprovisionamiento de Servicios

Tácticas
Decidir las tácticas más adecuadas para el Plan de Servicios de una empresa durante los
próximos dos años
Será más significativo si la empresa es donde trabaja actualmente
Si eso no es posible imaginar una típica empresa - que podría ser una empresa en la que
haya trabajado en el pasado
Para centrar sus decisiones, en primer lugar anotar aquí:

El sector de la empresa : ………………………………
Su posición: CIO o Arquitecto Jefe
El actual nivel de madurez de SOA :

Aprendizaje | aplicación | integración | organización | ecosistema
Motivos para la adopción de SOA:

....................................................................................................
…………………………………………………………………………
…………………………………………………………………………
Niveles de Madurez
Nivel Foco del Características

Proyecto
5 Ecosistema Transformación del Gestión y Planificación Integrada de TI y de Servicios
Negocio Funciones y responsabilidades alineadas con SOA
Soporte a Servicios en el ámbito del ecosistema
Muchos servicios se han convertido en estándares omnipresentes dentro y
fuera de la organización
4 Organización Servicios Proyectos sobre procesos colaborativos y repetibles

Compartidos en la Arquitectura de referencia extendida para incluir intercambios amplios y
Organización sofisticados, con la seguridad y confianza necesarios.
Servicios a nivel de Organización
Soportado por estándares y procedimientos basados en la medida y
monitorización de sistemas
3 Integración Servicios Proyectos que soportan procesos repetibles para la prestación de servicios
Compartidos en de Dominios y Lineas de Negocio
Dominios Control centralizado de toda la actividad de integración
Arquitectura de Referencia e implementación basada en la experiencia de
PoC
Todos los tipos de Servicio (process, capability, core business, utility)
2 Aplicación Proyectos enfocados Bastante infraestructura
a Servicios Servicios basados en Lineas de Negocios (LOB) o de Dominio que pueden
ser ampliamente reutilizados.
1 Aprendizaje Prueba de Concepto Experimentos Controlados

Actividad Inicial SOA
Decidir Tácticas (1 of 3)
Que tácticas considera más apropriadas para ‘la compañía’ en los proximos 2 años
1 Tácticas de Consumo de Servicios: Sólo servicios internos | + partners de confianza | +

servicios albergados externamente (read-only) | + servicios albergados externamente
(actualización) | no consumo de servicios
2 Tácticas de Provisión de Servicios: Construidos sólo para uso propio | + Aprovisionamiento

para Partners | + Aprovisionamiento para Clientes | + Aprovisionamiento para Público |
Aprovisionamiento para la venta, incluido albergue | Aprovisionamiento para la venta, el
comprador alberga | no construcción de servicios
3 Tácticas de Planificación de Servicios : Plan para la Empresa entera | … con algunas

exclusiones | para el mayor Departament o división | Plan para un sólo Proyecto | Plan
para un Ecosistema incluida la empresa | no hay Planificación
4 Secuencia de Adquisición: Servicios planificados y adquiridos con antelación | Servicios

adquiridos ‘por Oportunidad’ | Servicios sólo adquiridos cuando la Solución lo requiere
5 Fuente de Servicios Preferida: Desarrollo Interno| Adaptar Legacy| Adquirido a un ERP |

Uso de fuentes externas
6 Patrocinio del SOA (presupuesto y compromiso) viene de: Negocio | Principalmente IT |

Principalmente de un Proyecto.
Quien es el sponsor? ………………………………………………………………….
7a Los Objetivos del Patrocinador son:
Reutilizar sistemas legacy y/o pre-existentes servicios | Integración de sistemas,

compartición de procesos | Rápida entrega y modificación | Ahorro de Costes | Mejora de
la calidad de los sistemas | Portfolio de software altamente adaptable | B2B services |
Legacy Modernization | ………......
8 Triage (o Priorización) : Core Flexible – Enfoque Contexto Estandarizado | Enfoque CBI

(Critical-Business Issue) | Desarrollo de un Proyecto | Dependencia de Dominios |
Reemplazo de Sistemas Legacy | Actualización de Plataforma o Hardware
9 Prácticas de Desarrollo (procesos y/o tecnicas) SOA: Implantación de nuevas prácticas de SOA
| Adaptación de práticas ya existentes | Práticas existentes adecuadas para SOA | Ninguna
10 Organización del Desarrollo: Reorganización para SOA (ej.: nuevos equipos de gente) | Con la
estructura existente, pero introduciendo nuevos roles | En gran medida la misma estructura
de organización y Roles
11 Tecnología: Web Services | Mensajes XML | middleware orientado a mensajes | CORBA |

Technología de Componentes | Producto ESB (Enterprise Services Bus) | Combinación de:
……………………………………………………………..
12 Secuencia de Diseño de la Plataforma SOA (o ESB): Antes de la Planificación de Servicios |

Después de la Planificación | en paralelo con la Planificación | no aplicable, no Planificación
Definir Políticas de Fuentes de Aprovisionamiento
Escribir 1,2,3 en cada columna, para mostrar las fuentes preferidas para el nivel de
particularización — para ‘la empresa’ basado en las tácticas seleccionadas
Nivel de particularización —> commodity estandarizado especializado experimental
Pre-existente, comercialmente disponible
Pre-existente, en Paquete adquirido
Pre-existente, ofrecida por partners
Construción interna por partners
Ensamblando Servicios Existentes

Añadir otras fuentes si son necesarias
Funciones Legacy, wrapeadas como servicios
Componente Software adaptado como servicio
Estándar industria, costrucción externa
Especificación interna, construcción externa
Especif. interna, constr. y despliegue ext.
Especificación, construcción despliegue interno
de Servicios:
Modelización SOA
Politicas de Diseño y Arquitectura de Servicios

Definiendo la Arquitectura / Politicas de Diseño
Esta sesión describe las políticas para la Arquitectura de Servicios y

Diseño de Servicios
Directivas y lineas maestras para el gobierno de:
Capas de Servicios y dependencias permitidas
El Diseño de servicios individuales
Sales
Solution Layer
System
Orders Process Service Process Services
Orders Service
Core Business Services
Products Service
Utility Services
Accounts Receivable Underlying Services
Contenido del Plan de Servicios: estamos aquí

Progreso
para el entregas de
para SOA Fuentes y
Servicios para el
Progreso
Dominio <Dom3>
Progreso
la Arquitectura
la Arquitectura
la Arquitectura
Transición
Despliegue de
Aproximación la
para
Transición
Automatización
Enfoque de la
Política de estilo de Servicio

Patrones de Operación Reglas de Capas y Dependencias
Documentación
Sanity Check
Políticas de Supresión y de Identificación
Implementación de Políticas
Arquitectura de Capas
“Una subdivisión jerárquica dentro de la arquitectura del sistema”.

Los objetos de una capa: :
Sólo realizan las funciones permitidas para esa capa
Sólo se comunican entre sí o con objetos de la capa de abajo
La construcción de software en capas hace que sea más fácil de mantener:
Deshace la programación monolitica,
Role de cada objeto de software es limitado, pero claro
Lasagna en lugar de Spaghetti Los Objetos de una capa
pueden comunicarse
Las comunicaciones entre

Capas usan protocolos
Capa Superior
especificos
Capa Inferior La Capa inferior actúa como

un proveedor de servicios.
La Capa inferior no puede
En la práctica: llamar a la superior
Las reglas varían dependiendo de la capa
Puede haber llamadas hacia arriba en circunstancias especiales
Políticas sobre Capas de Servicios
¿Cuantas capas?
¿Cual es el rol de cada capa?
Reglas sobre la independencia de servicios en cada capa
Capas de Servicios
Se proponen seis capas básicas:

Solution layer (Capa de aplicaciones. Sólo consume servicios)
Process Service layer (reglas de cadena de valor, coordina otros servicios)
Capability Services Layer (orquestación de servicios básicos)
Core Business Service layer (servicios reutilizables propios de la organización)
Utility Service layer (lógica comun, áltamente compartible)
Underlying Service layer (servicios dificiles de desarrollar)
¿Por qué hacer esto?

Un buen sistema de clasificación Otras capas a considerar:
Una forma de lograr
* Control Flow Layer
la mejora de la mantenibilidad * External Usage Layer
mayor grado de reutilización y distribución * Infrastructure Service Layer
estandarización en las capas inferiores * Exclusive Service Layer
diferenciación en las capas superiores
especialización de labores
Ejemplos de Servicios asignados a cada Capa
Paquete Gestión de Análisis de SOLUTION

CRM Ventas
Financiero Suministros Mercado/Ventas LAYER
Gestión del Cambio Proceso de Venta

Mejorar Estructura Org. PROCESS
RFQ-to-Stock Process Gestión Campañas SERVICE
Preparar Cuentas Trimestrales Des. Nueva Oferta LAYER
Revisión de Stocks Calcular minimos Compras CAPABILITY

Preparar Cuentas SERVICE
Fidelizar Clientes Preparar Previsiones Ventas
LAYER
Presupuestos Pedidos CORE

Productos Potenciales
Unidades Org. Productos BUSINESS
Campañas/Promociones Previsiones Ventas SERVICE
Cuentas Clientes
LAYER
Calendario Cia. Ubicaciones Oficinas Directorio Empleados Cálculo Comisiones

UTILITY
Calculo de Impuestos SERVICE
Planificador Recursos Formateador Direcciones Cál.InteresComp. LAYER
Agenda
Acceso a Pqt. Contabilidad UNDERLYING

EntidadNegocioGenerica SERVICE
ProcesoAprobacionGenerico
Servicio de Facturación (terceros) LAYER
Conceptos
Capa: Operaciones: Dependencias: Mas reglas: Almacenamiento de

Rol principal datos:
Solution Logic: Inexistentes. Esta Puede llamar a un proceso, Interfaz de usuario, No excepto datos
Proporciona experiencia capa no contiene a un core service, o a utility validación, menmsajes de temporales de la sesion
del usuario final servicios y underlying directamente usuario, gestion de sesiones
Process Services: Independiente del Puede llamar Puede ser llamado No es su objetivo.
aplica reglas específicas interfaz de usuario, directamente, a un directamente por soluciones Excepcionalmente datos de
de procesos de negocio representa a capability ,core service, o de negocio control, realizados por
procesos a utility y underlying motores de procesos.
CapabilityServices: Independiente del Puede llamar Puede ser llamado por No es su objetivo. Sólo en el
orquesta otros servicios; interfaz de usuario, da directamente, a un core soluciones o process caso de que no sean
composicion servicios respuesta actividades service, o a utility y services almacenados por ‘core
complejos de procesos underlying services’
Core Business Independiente del Puede llamar a otro core Generalmente las Normalmente mantiene los
Services: interfaz de usuario y de service, o a utility y dependencias ciclicas no principales almacenes de
aplicar reglas que afectan procesos, por lo que underlying son permitidas. No puede datos a menos que esté
a toda la organización puede ser utilizado en llamar a servicios de delegado en utility o
distintos conceptos proceso underlyig services
Utility Services: Independiente de Puede llamar a otro utility Generalmente las A menudo utilizados para en
Compartidos por los interfaz de usuario, y underlying dependencias ciclicas no directorios, en tablas y
Core Business Services procesos y a menudo son permitidas. rastros de auditoría, etc
de los dominios
Underlying Services: genérico, basado en Podría llamar a otro No puede llamar a process o Utilizados para mantener
aplican reglas de aplicación, interfaz no underlying, pero no es core services almacenes de datos, y
negocio, pero de difícil propio para desarrollo muy común llamadas a servicios
desarrollo
58 interno
Definición de Dependencia entre Servicios
El servicio A depende del Servicio B si el servicio A no puede funcionar sin que el

servicio B esté disponible.
Dependencia
Service A
«llamada»
Service B
Significa que el servicio A requiere al servicio B para realizar una o mas operaciones
Especificación de Arquitectura con dependencias. Ejemplo.
Desarrollo de Control de
Pedidos Productos Stocks
Solution Layer
Servicio
Cumplimentación Servicio Gestión Process Services
de Pedidos de Stocks
Servicio Movimientos de Stock

Pedidos Servicio
Productos Core Business
Compras de Stocks Services
Servicio
Clientes
Conversor de Moneda
Utility Services
Formateador de Direcciones
Cuantas a Pagar Compras Underlying Services

(desde el sistema de Contabilidad) (de un componente genérico)
Dependencias Permitidas
Solución 1 Solución 2 Solución 3
PROCESS SERVICES
UTILITY SERVICES
UNDERLYING SERVICES
Dependencias no permitidas
Solución 1 Solución 2 Solución 3

PROCESS SERVICES
Dominio 1 Dominio 2
(ciclica)
UTILITY SERVICES
(ciclica)

UNDERLYING SERVICES

Tipos de dependencias entre Servicios
Servicios Independientes
No acceso al codigo o datos del uno al otro
No llamadas de uno al otro
Reusable en otros contextos, sin necesidad del otro
Cada uno puede ser implementado en un componente encapsulado
Servicios dependientes Aciclicos (dependencia de 1 via)

Servicios hacen llamadas de uno a otro:
Pero no ocurren operaciones ciclicas
Pueden ser implementados en un componente encapsulado
Servicios dependientes Ciclicos (dependencia de 2vías y circulares)

Menos código, más potentes
Más complejos de probar y mantener
La “madre de todos los males” (mother of many evils)
Sanity Check
Un filtro que ayuda a decidir si adquirir un servicio o no

Definido dentro de las Políticas
Por ejemplo:
El servicio debe soportar al menos dos de las siguientes premisas, sino no será provisionado:
ofrecer operaciones que puedan ser compartidas por mas de un proceso, aplicación o
interfaz de usuario
ofrecer operaciones que puedan ser emsambladas dentro de servicios de mayor nivel
ofrecer operaciones que puedan ser orquestadas por mas de una secuencia de servicios
proporcionar acceso programatico a operaciones que usarán colaboradores (B2B, B2C,
…)
reunir información de varias fuentes de datos que proporcionen visión de 360° de los
principales recursos de la organización
permitir a un sistema existente tener acceso a otros sistemas y a aplicaciones que deban
integrarse
Reforzar la estandarización de procesamiento a través de la organización
proporcionar acceso a funciones de alto valor para terceros no disponibles in-house
(commodity services, o funciones especializadas)
Estilo de los Servicios
Asincronos o sincronos?
Son preferibles las operaciones asíncronas pero si los imperativos operacionales lo
exigen, se pueden usar sincronas.
Las operciones asíncronas no son bloqueables por consumidores (estan menos acopladas)
RPC o XML
Parámetros de entrada y/o salida estilo RPC
Preferible documentos XML ya que el diseño del mensaje puede ser cambiado sin
necesidad de consumir código. Esta más débilmente acoplado
Comportamiento transaccional
Usar ‘two-phase commit’ o usar compensación de transacciones
Considerar la adopción del estándar WS-Coordination (incluye ambas)
Actualización de Servicios
Permitir o no versiones concurrentes
Que hacer con las versiones obsoletas
Otros
Control de Concurrencia, Carga util (standard payload), Errcode, Excepciones, ...
Documentación de Servicios
Estandares típicamente necesarios para:

De nombres de Servicios, Operaciones y Automation Units
Entradas en el Catálogo de Servicios o Directorio
Especificación de Servicios
Pruebas de Servicios y sus resultados
Service Level Agreements
Que estándares se necesitan

Iniciar proyectos para definirlos
Los Planificadores deberán definir las políticas a ser aplicadas en
estos proyectos
Integridad Referencial, Identificación, y politica de Borrado
Integridad Referencial
¿Cómo se mantiene la integridad referencial de las ocurrencias a instancias
que son competencia de otro servicio?
No es problema para servicios que comparten una base de datos unica
Lo es cuando una instancia va a ser borrada y tiene referencias externas.
Identificación de Instancias
Instancias de las que un servicio es responsable de mantener las
referencias a otras instancias de las que otro servicio es responsable.
Usar los identificadores existentes, tal como se conocen en el negocio
No son inmutables, y pueden cambiar
Puede no ser utilizable en instancias que referencian a paquetes
Obstaculiza la provisión de servicios generalizados
Usar identificadores internos ‘ad hoc’
Decidir formato estándar Politicas
de Borrado de Instancias
Imutables, ‘ad hoc’
Borrado físico vs lógico
Puede no ser adecuado para instancias
que referencian a commoditys o servicios Supresión de los “borrados lógicos”
externos
Politicas de Arquitectura y Diseño de Servicios. Resumen
Politicas de Arquitectura influencian toda la estructura del Plan de Servicios

Las políticas de Arquitectura se refieren a:
Capas de Servicios
Reglas de Dependencia de Servicios
Sanity Check de Servicios propuestos
Politicas de Diseño estandarizan ciertas caraterísticas del diseño de Servicios:

Estilo de Servicios
Integridad Referencial, Identificadores y Borrado
Estándares de Documentación
Recomendaciones para las Políticas

Cada organización necesitará establecer sus propias recomendaciones
Las políticas pueden ser ajustadas a medida que se adquiere experiencia SOA
de Servicios:
Modelización SOA
Priorización en la Planificación de Servicios

Triage en la Planificación de Servicios
¿Qué significa Triage (Priorización) en la Planificación

de Servicios?
Priorización basada en "Temas críticos para el

negocio"
Priorización basado en "Core versus Contexto”
Triage
Acción de seleccionar procesos en función de la calidad
En medicina: la asignación de grados de urgencia a heridas o

enfermedades para decidir el orden de tratamiento de un gran
número de pacientes
En la planificación de servicios: clasificación de artefactos de

acuerdo a sus características, para decidir la urgencia y el
estilo de tratamiento dentro de la planificación y de suministro
de servicios
Más simplemente
categorización - decidir si algunos dominios y/o servicios
deben ser tratados de modo diferente
priorización - decidir por qué dominios y servicios
comenzar
Técnicas para el Triage
Critical Business Issue (CBI)

adaptado del libro de Rummler and Brache “Improving Performance” (mejora del
rendimiento)
Sistema metódico, enfoque intuitivo
Adquirir los servicios que ayudarán a resolver las cuestiones críticas de negocio
Analisis “Core-Context”
adaptado de los libros de Geoffrey Moore's “Living on the Fault Line” y “Dealing
with Darwin”
Separa las actividades empresariales en núcleo (core) y el contexto
Los Procesos Core son los diferenciadores de la compañía y precisan de una
mejora continua
Los Procesos del Contexto deben ser eficientes y serán normalizados
Esta separación guía el abastecimiento de servicios y la utilización de recursos
Critical Business Issue
“Un problema o una oportunidad que es fundamental para el éxito general

de la organización” o
“Una amenaza o una oportunidad que es fundamental para el éxito de la
estrategia de negocio”
Ejemplos de CBI:
Un actual o potencial gap entre el rendimiento de la compañía y:
El rendimiento de la competencia
Las expectativas de los clientes
Analizar las diferencias; estimar el retorno de la inversión para el cierre del gap
Una oportunidad para realizar mejoras significativas en un área aunque no
experimente problemas de rendimiento
La necesidad de implementar un cambio importante en el negocio:
lanzamiento de un nuevo producto, entrada en un nuevo mercado,
cumplimiento de una nueva regulación, …
SOURCE: RUMMLER & BRACHE
Critical Business Issue- Impulsor de mejoras
Determinar Estrategias Negocio

Identificar Proceso de Negocio Explicar las vías para llevar a cabo
las estrategias de negocio
Identificar Critical
Identifca rprocesos Core
Business Issues
CBI = las amenazas u oportunidades
fundamentales para el éxito de
Detectar que procesos
la estrategia de negocio
Causan Problema /
Soportan Oportunidad
Procesos Core son los que son más

críticos para la aplicación de las
Decidir las CBIs a resolver
estrategias de negocio
Establecer metas para los

Procesos que incluyen CPIs Identificar los Dominios de los procesos
Mejora Continuada
priorizados
Si el proceso es transversal, puede ser
Priorizar Procesos basados en
gran impacto de CBIs
necesario trabajar en fragmentos del
Plan dentro de cada dominio
Ejecutar proyectos de
Mejora de Procesos SOURCE: RUMMLER & BRACHE
Triage a partir de Critical Business Issues
Lógico, conservador
No amenazante para la gestión
Apunta a los procesos de negocio y, por lo tanto a dominios que es donde

los arquitectos deben centrarse primeramente
Prioriza Procesos de Negocio
El objetivo de análisis son los Critical Process Issue (CPIs), o
procesos de negocio problemáticos
Las nuevas soluciones software basadas en servicios resolveran
los CPIs y por lo tanto tambien los CBIs
CBIs, CPIs y Objetivos: Ejemplos
Problema Critico (CBI) Proceso de Negocio Problema del Proceso (CPI) Objetivos (para el final del año próximo)
Introducir nuevos Desarrollo de Ciclo de Tiempo demasiado largo para el Nuevos Productos a ser lanzados en menos de 2
productos en los nuevos prouctos desarrollo y la comercialización de nuevos años Extensiones de linea lanzados en menos de
próximos 18 meses productos 6 meses
“ Lanzamiento de un Cada lanzamiento necesita un proceso a Desarrollo de métricas para monitorizar la
nuevo producto medida eficiencia del lanzamiento
Mejorar el Margen en Cumplimentación Costes de reparto mayores que los de la Reducir el Coste de Reparto Unitario en un 40%
la linea XYZ de Pedidos competencia
“ Compra de Materias Los costes de materias primas continuan Materiales Comprados <= 30% del revenue
Primas siendo el 50% de la facturacion (revenue)
“ Fabricación de Gran cantidad de productos rechazados por Reducir rechazos en un 90%
Productos Finales el Control de Calidad
Mejorar satisfacción Pagos de Clientes Los errores de facturación molestan a los Sólo <=0.5% de facturas contengan errores
del cliente clientes y consumen demasiado tiempo Sólo <= 2 quejas válidas de clientes por errores
de facturación al mes
“ Cumplimentación Alto número de Pedidos devueltos debido a Reducir el número de devoluciones por daños de
de Pedidos daños en el transporte transporte al <=0.01% de las entregas
Incrementar la cuota Marketing del Solo el 10% del mercado potencial es Aumentar la concienciación al 80%
de mercado Producto XYZ consciente de la existencia del producto XYZ Hacer disponible XYZ a través de nuestra fuerza
Sólo se vende en grandes almacenes directa de ventas y el sitio web
“ Ventas del Producto El Personal de ventas no entiende la función 100% el personal de ventas capacitado en la
XYZ) del producto función de producto
76 ADAPTED FROM: RUMMLER & BRACHE www.swassociatesint.com

Categorización de Actividades en Core y Contexto
Las actividades Core crean ventajas

competitivas y diferencian a la Las actividades
organización dentro del mercado. Actividades Actividades de contexto no
Elevan el valor de las acciones del Nucleo (Core) de Contexto incrementan el
valor de las
acciones;
Un déficit aunque si se
en estos Actividades de hace mal, el
DIFERENCIACION ESTANDARIZACION precio caerá
Procesos
Misión Crítica
producen
graves
riesgos
Se debe
mantener
un alto
grado de Actividades
EXPERIMENTACION EXTERNALIZACION
control de Soporte
Comprometer los mejores talentos. Coherente y eficaz, similar

La supervivencia depende de ello con la competencia
Adapted from: Dealing with Darwin, 2005, by Geoffrey Moore

La importancia de un Nucleo flexible
Hacer foco en que el núcleo de procesos de negocio sea flexible:

Motor del cambio
Soporte a la innovación
Requiere que el software que soporta el núcleo procesos de negocio sea
altamente adaptable
Capaz de admitir variantes de soluciones para
Nuevos canales, mercados, productos, competencia
Usuarios internos y externos
Diferentes lenguajes y reqerimientos legales
Capaz de respaldar customizaciones locales
de modo que los usuarios y analistas puedan configurar el sistema
para procesos de negocio apropiados
Las soluciones para los procesos de negocio debe ser diseñadas de forma
flexible
La importancia de un Contexto estandarizado
Reduce los costes de mantenimiento y actualización del software

Reduce los costes de formación – más fácil de cambiar funciones y roles
Cada proceso ha de ser tan eficiente como un estándar de la industria

Puede externalizarse el proceso, si no es de misión crítica
Se pueden comprar paquetes y servicios commodity para apoyar el proceso
Para algunos procesos y software la estandarización es lo más adecuado

Determinados analistas sugieren que el 80% de la actividad de negocio
cae dentro de esta categoría
Encontrar ese 80%, permitiría dedicar energía a las actividades de
diferenciación presentes en el core
Clasificando Dominios como Nucleo o Contexto
context !
Un Business Domain es contexto, si contiene:
Sólo Procesos de contexto
Sólo entidades (business type) de contexto
Un Business Type es contexto, si todos sus atributos y relaciones
son estándares de la industria, o puede también ser
Comparar con un modelo de la industria, o con los datos que se
almacenan en un paquete de software
Es normal encontrar una mezcla de entidades y/o procesos en los Dominios,

de forma que es dificil separar en subdominios, en este caso finalmente se
considera el dominio completo como ‘core’
Si el 80% es Core se considera como core
Si mas del 20% es core y mas del 20% es contexto interesa dividir el dominio
en dos uno core y otro contexto
Sesión Triage — Resumen
Triage … realizado sobre dominios

¿Deberían ser todos tratados de la misma forma?
¿Que debe planificarse en primer lugar?
Enfoque impulsado por problemas críticos (CBI, CPI):

Critical Business Issue-Driven (CBI) = Una amenaza o una oportunidad
sobre la cual pivota el éxito de la estrategia de negocio
Estrategia CBIs CPIs priorizar procesos priorizar dominios
Enfoque impulsado por Nucleo/Contexto:

Para un proceso tipo Contexto, debería adoptarse un estándar, al no tratarse
de un proceso diferenciador
Por lo tanto las soluciones de software y servicios deberían ser tambien
estándares
Para un proceso diferenciador tipo Núcleo, debería adoptarse procesos
basados en la mejora continua, la innovación y el control por parte del
negocio.
El apoyo a soluciones de software, y servicios utilizados, deben apoyar
el cambio y la variación
de Servicios:
Modelización SOA
Modelización de Conceptos de Negocio

Core Business Services y Business Concepts
Core Business Services forman Business Concepts

la espina dorsal del Portfolio de Representan a los recursos
Servicios (entidades)
Cada ‘core business service’ esta Se relacionan entre ellos
centrado en un recurso del cual la
Tienen estados que soportan
organización necesita guardar
operaciones (creación, actualización,
datos
traslado, seguimiento, . . . )
Por ejemplo:
Proporciona una visión de 360° del
Employee Services recurso
Product Services
Purchase Order Services
Customer Services
General Ledger Services
En el estudio de Ontologías se
aprende a trabajar con modelos
Location Services
semánticos
Ejemplo Implementación usando Servicios compartidos
Portal del Ciudadano
Portal del Estudiante
Consultas Plazas de Préstamos Cuidado de

Justicia estudiantes estudiantiles Niños
Universidad Gestión Financiación Sector

Universidad
Sector Universidad Servicios
Justicia Sector Educacion Sociales
Bus de Servicios de Educación
Recursos Servicios Recursos Servicios Recursos Servicios Recursos Servicios Recursos Servicios Recursos Servicios
Libertad Cond Prisionero Estudiante Universidad Plazas Univ. Plazas Guardería
Bus de Servicios de Gobierno

Recursos Servicios Recursos Servicios Recursos Servicios Recursos Servicios Recursos Servicios
Identidad Ciudadanos Gestión Cuotas Plazas

Para soportar Servicios Compartidos se necesita compartir
conceptos
Gestión
Modelo semántico correspondiente al caso
del slide anterior.
Consultas Justicia Universidad Préstamos Cuidado de Niños
Prisionero Estudiante
Ciudadanos
Un modelo simple, via abstracción
generalización agregación clasificación
Restau- Política de
Hotel Comida Recibo
rante devolución
Reglas
fiscales
Viajes y Dietas
Alojamiento y
Gastos
Manutención
La aplicación de diferentes tipos de abstracción a una situación de negocio nos lleva a

un método de ir hacia un modelo de reconocimiento de la semántica de la organización.
Dos visiones: Separadores y Agrupadores
(Lumpers y Splitters)
Separador:
“Hay diferencias importantes entre Jack and Jill, por lo que
pertenecen a diferentes tipos.”
Jack se cayó y … y Jill se

se rompió la cayó, pero
rodilla … no se dañó.
Agrupador:
"Jack y Jill son esencialmente lo mismo, y pertenecen al
mismo tipo".
Subtipos y Herencia: varias notaciones
PERSONA PERSONA
is-a
PERSONA
PACIENTE NO-PACIENTE
PACIENTE TRATAMIENTO
Todos los pacientes son Personas. Pero no todas las personas son pacientes.
Tanto Jack como Jill son instancias de Personas.
Jack es un ejemplo de paciente, Jill no lo es.

Desacoplando Capas de Abstracción
PERSONA
Modelo Agrupador
TRATAMIENTO PACIENTE Modelo Separador
El siguiente paso consiste en disociar los dos puntos de vista.

Ahora podemos representarlo en dos modelos con un mapeo adecuado entre ellos.
Servicios desacoplados
PERSONA
Otros Servicios
*
TRATAMIENTO PACIENTE Servicios Medicos
ANIMAL Otros Servicios
La disociación semántica nos permite desacoplar los servicios
Desacoplando Identidad, Seguridad, Privacidad, Contexto
PERSONA
Otros Servicios
*
CRIMEN CRIMINAL Servicios Justicia
AMENAZA
Seguridad Patria
NACIONAL
La disociación de la semántica también ayuda a gestionar la identidad, la seguridad, la

privacidad y el contexto: Por ejemplo, desacoplando a una persona de su registro criminal.
La semántica es critica para la interoperabilidad
HOSPITAL BANCO BIBLIOTECA

"Cada vez que Jack "Jack y Jill tienen una "Cuando Jill era estudiante,
es admitido en el cuenta corriente tenía un carné de estudiante.
hospital, se abre un conjunta, por lo que Ahora ella es un miembro del
nuevo registro de consideran como una staff, está registrada a través
paciente". única instancia de la de un sistema diferente ".
entidad Clientes".
Obviamente, esto no importa

siempre y cuando el Banco no
quiera compartir los servicios
con el Hospital o la Biblioteca.
Bajo la visión de SOA,

estas diferencias
causan problemas de
interoperabilidad.
Interoperabilidad a través de un modelo semántico
Solución a los problemas de

Otra Agencia interoperabilidad: Modelo Semántico
Tributaria
En el ejemplo, el Modelo proporciona
una semántica única para todas las
Organismo del referencias a los contribuyentes a través
Sector Público de todos los sistemas e interfaces.
Para la autoridad fiscal

Interacciones con los contribuyentes
Agencia
Contribuyente Interacciones sobre los
Tributaria
contribuyentes con otros
organismos y terceros
Entidad Para el Contribuyente

Financiera
Interacciones con autoridad fiscal
Interacciones con otros organismos
y terceros que puedan afectar a
Gestoría temas fiscales
Distintas visiones
Modelo Canónico Modelo de Interoperabilidad
Construir modelos semánticos estándar Construir multiples modelos semánticos

a traves de toda la organización e
incluso de fuera de esta Representando la perspectiva del
cliente
Desacoplar la semántica Representando sistemas y servicios
Desacoplando los sistemas de terceros
Desacoplando el negocio Representando los sistemas
legados
Construir puentes semánticos entre

organizaciones, sistemas y servicios, a
Los analistas deben asegurarse de
que los Modelos tienen sentido para traves de diferentes Modelos
el negocio y sus colaboradores
de Servicios:
Modelización SOA
Modelización de Entidades (Business Types)

Donde estamos

Preparación
del Modelo
Definir Políticas de Planificación y Aprovisionamiento
Utilización del Utilización del
Modelo de Alto Modelo
Modelos de Nivel Realizar acciones de Priorización (Triage) Detallado
Negocio
Decidir Ambito y Planificar Iteraciones
Arquitectura de
Modelo de Obtener Modelos Detallados de Negocio Especificación
Dominios de Servicios
Modelo E/R Descripciones
Refinar Políticas
detallado Identificar Otros Servicios y Dependencias de Servicios
Modelo de Arquitectura de
Funciones Identificar Unidades de Automatización y Depen.
Implementación
de Servicios
Modelo de Diseñar Arquitectura de Despliegue de Servicios
Procesos Arquitectura de
Desplieguede
Modelo de Servicios
Sistemas
Publicar la nueva Release del Plan de Servicios Plan de Servicios
Business Type Model: Modelo Entidad/Relación
Que es un modelo Business Type

Porque hacerlo
Cuando se hace
Purchase placed with Supplier Business
Atributos & Asociaciones Order * 1 Party
Subtipos y Super-tipos 1
Identificadores includes
Construcción de un Modelo *
Business Type Purchase specifies Raw Material Associate
Order Line * 1 Company
Modelos de alto nivel versus
detallados
Que es una Entidad (Business Type)
Un tipo de objeto de negocio que representa aquello de lo que una compañía

necesita guardar datos en los sistemas informáticos
Instancias de Business Types Business Types

Acct 1234
Empleado
Ubicación
Acct 0045
Cuenta
Acct 9133
nueve objetos tres categorías de

dentro de
de negocio objetos de negocio
Business Type Model (BTM)
Modelo Entidad/Relación no canónico

Define los datos que la organización necesita Un Business Type Model es:
para operar su negocio. Un diagrama +
Aquellos conceptos de negocio de los que la Documentación del Modelo
organización necesita guardar datos
Incluye:
Pedido Proveedor business types (Entidades),
Numero pedido{id} enviado a nombre {id} pero no instancias
0..* 1..1 individuales
Fecha pedido dirección
Total importe asociaciones entre
1..1 entidades
consta de atributos (data items) de
1..* {id}
entidades
identificadores de
Linea de Pedido
entidades
{id}
Codigo producto
cantidad
precio
Concepto y Utilidad de un Modelo E/R
General Para SOA

Un ejercicio util, cuyo resultado es un En la planificación de Servicios
activo valioso (un modelo del negocio) Se utiliza para subdividir la
Reduce la ambiguedad de terminología organización en dominios de negocio
de negocio Se utiliza para identificar un conjunto
Describe los recursos que utiliza la de los principales servicios prestados
organización, y cómo se relacionan a la organización que proporcionan el
Dibuja reglas de negocio asociadas a núcleo de la lógica de negocio a
datos compartir en un determinado dominio
Da una visión consistente de toda la (Core Business Services)
empresa
Se construye bajo criterios de
Describe los datos que los sistemas
flexibilidad ‘aflojando’ las
operacionales necesitan mantener,
independientemente de la aplicación o relaciones entre entidades.
tecnología de almacenamiento Tras la planificación de Servicios
Base para el diseño de la BBDD que Subconjuntos de objetos de negocio
soporte los datos de la organización utilizados para definir los datos que
Referencia util para la selección de intercambia un servicio, lo que forma
paquetes de software parte de la especificación del servicio
Atributos
Customer
Los Atributos son características de la entidad (business type)
name
P.ej: cada Cliente tiene su nombre, dirección y dirección web
address
web site address
Para cada instancia, los atributos toman diferentes valores
name = Adidas(UK) Ltd
address = Pepper Road, Hazel Grove, Stockport, Cheshire SK7 5SA
web site = http://www.adidas-salomon.com/
Supplier
Cada atributo tiene un tipo de dato (data type) order number
P.ej: number, date, text, composite, boolean supplied product codes
No es necesario definirlos durante el Plan de Servicios supplier performance
Se definen para la documentación de Implementación address city
supplier date
date became approved
Evitar: atributos duplicados o derivados, asignación a tipos de datos supplier
erróneos, nombres no significativos, …
duration since became
approved
current status
Asociaciones: Relaciones
Muestra como se relacionan las instancias de diferentes entidades

El nombre de la asociación indica como se relacionan
Se registra el multiplicador que caracteriza a cada relación (cardinalidad)
Pedido Proveedor
0..* recibido por 1..1
Numero pedido nombre
Fecha pedido direccion
Total importes
0..* significa minimo cero, maximo muchos 1..1 significa minimo uno, maximo uno
Puede abreviarse a * Puede abreviarse a 1
Un Proveedor recibe de Un pedido es recibido
cero a muchos Pedidos sólo por un Proveedor
Normalmente la asociación lleva un nombre.

Se lee de izqda. A dcha. Y de arriba a abajo:
‘Purchase Order received by Supplier’,
Nunca ‘Supplier received by Purchase Order’
Cardinalidad
Entidad
1
atributo 1 Uno, exacto
atributo 2
Entidad
0..1
atributo 1 Cero o uno
atributo 2 (opcional)
Entidad
1..* Uno o muchos
atributo 1
atributo 2 (1..n)
Entidad
* Cero o muchos
atributo 1
atributo 2
Entidad
2 .. 10 Minimo dos,
atributo 1
atributo 2
maximo diez
SOA y Flexibilidad
Una SOA debe buscar la capacidad de atender cualquier situación futura

La flexibilidad comienza por no ‘atar’ las relaciones entre los datos
Un Modelo flexible aproximaría las relaciones a una cardinalidad *..*
Pedido Proveedor
0..* recibido por 1..*
Numero pedido nombre
Fecha pedido direccion
Producto
El pedido de un producto puede ser hecho a varios proveedores

La complejidad que pueda suponer una relación *..* se resolverá en la fase
de implementación.
El servicio quedará especificado con dos direcciones.:
Una via 1..* y otra vía *…1,
y las reglas de dirección
Subtipos y Supertipos
Una entidad puede ser subtipo o supertipo de otra(s)
La flecha va de subtipo a supertipo

Trabajador
id Se lee “es un tipo de”, en la dirección de la
first name flecha
last name
Autónomo es un tipo de Trabajador
{complete} Asalariado es un tipo de Empleado
employeeType Un subtipo hereda todos los atributos y
employeeType
Autónomo
asociaciones de sus supertipos
agency id Empleado Un supertipo puede ser particionado en
start date joining date subtipos de varias formas
end date job title
next review date Propiedades de la Partición :
role nombre, que se muestra en la flecha
{complete}
{completa} cuando todas las instancias
pertenecen a un subtipo
Director Asalariado Becario {solapada} cuando una instancia puede
reportee [*] annual salary hourly rate
pertenecer a más de un subtipo
authorization level healthCareOption overtime rate
hours this week
Particiones Múltiples y Herencia Múltiple
Herencia múltiple (utilizar con precaución)

Cada Vehiculo es a la vez un transporte y un
elemento asegurado
Transporte Asegurado
Facility
Partición completa
Un Camión puede ser Rigido o Articulado (OR)
Tipo de Partición Solapada (utilizar con precaución)
transporte insurance
Tipo de Un Coche puede ser tanto Descapotable como
category
transporte de Gasolina (AND)
Barco Vehículo
Diesel
Tipo de Tipo de
vehículo vehículo
Camión Coche 4x4
Tipo de
Tipo de
Camión {completa}
Camión
Articulado Rigido {solapada} Descapotable
Una asociación puede representar composición o agregación
Agregación Composición
El componente podría existir sin El componente no puede existir sin estar

estar en un contenedor en un contenedor
El componente puede ser incluido El componente solo puede pertenecer a

en varios contenedores a la vez un contenedor a la vez
Convoy Club Window Pedido
0..1 * 1 1
incluye pertenencia incluye incluye

incluye
0..2 1..*
* *
Línea de
Envío Persona Scroll Bar
Pedido
107
Diagrama de Modelo Entidad/Relación (Business Type):
Ejemplo
Dominio Supply de una compañía que compra productos para la reventa
No se indican los Atributos, aunque podrían ser incluidos en el diagrama

Se necesita una convención para documentar las relaciones que atraviesan dominios diferentes
Identificadores
Clip
color
Cada instancia debe ser diferenciable de cualquier otra tamaño
Ninguno es
material identificador
instancia
Debe existir un atributo que posibilite que cada instancia de Pedido

numero {id1}
una entidad sea identificada fecha
importe
O bien, las instancias pueden ser identificadas mediante

una combinación de varios atributos y/o asociaciones
Empleado
id {id1}
nombre
Algunas entidades tienen varios identificadores apedillo
DNI {id2}
Pedido Linea de Pedido

solicita Producto
consta de numero pedido {id1}
numero pedido codigo
fecha 1 {id1} {id2} 1..* numero linea {id2} * {id3} 1 descripcion
codigo producto precio
importe
cantidad
Generalización: estabilidad y longevidad de las entidades
Formas de Generalización
Producto
Producto code
añadiendo espacio para description
code
futuros atributos description
unit type
retail price per unit
unit type
cost price per unit
retail price per unit
current state code
cost price per unit
note 1
note 2
ampliando el concepto de
Edificio Ubicación
negocio de la entidad: las name
name
instancias podrían ser location
position
description
edificios, calles, parques, description
etc. Empleado
id
start date
Empleado
desacoplando la entidad id

name
Persona
generica en una generica address name
start date category code
y otra que particularice address
birth date
birth date
Como desarrollar un Modelo E/R no-canónico
Realizar un workshop con expertos de negocio

Incluir un moderador, un modelador y un secretario (tomar notas)
Partir de Modelos Ontológicos (o de Modelos de procesos de negocio)
A un primer nivel discutir sobre entidades, relaciones, restricciones y cardinalidad.
Mas tarde añadir detalle de atributos, identificadores, etc.
Crear diagramas sobre una pizarra
No establecer límites de tiempo
“Aparcar” las cuestiones delicadas, si bien queden anotadas
Despues del workshop,
refinar los resultados y circular la documentación para obtener feedback
Organizar reuniones específicas o más talleres, para abordar temas aparcados
Chequear los resultados del workshop, y añadir más detalles examinando:

Modelos estándar de la industria para el dominio (tal vez su uso en el workshop)
Los datos almacenados en sistemas actuales
Literatura Corporativa (procedimientos, informe anual, …)
Examinar cualquier dato o concepto relacionado con modelos de negocio
Para los dominios que puedan ser estándares de la industria, se podría aceptar el
modelo estándar y saltar el modelado
Si no se está seguro, construir el modelo propio y comparar con el estándar
Elementos del Modelo
Buscar en los nombres (en expresiones y documentos)

Los nombres pueden ser entidades
comprobar que tiene varias instancias, y un medio para identificar cada una
algunos nombres pueden ser atributos o ejemplos de instancias
algunos seran entidades dependientes o redundantes
otros estran relacionados con TI y no con el negocio
Seran atributos
si es una propiedad o característica de la entidad que puede tomar varios
valores en cada instancia
Los verbos pueden indicar relaciones
que conectan instancias de dos o más entidades
tambien indican procesos, tareas y acciones
Simplificar el modelo
Introducir subtipos y supertipos
Identificar y eliminar redundancias y dependencias
Mejorar el modelo
estudiar el ciclo de vida del modelo
Comprobar la consistencia con los procesos de negocio
Exclusiones al Modelo
Excluir
Entidades en las que las instancias no son identificables
Entidades que los sistemas de la organización no gestionaran
Atributos y relaciones dependientes
a menos que los usuarios los necesiten
En cuyo caso nombrarlos con el prefijo “/” y proporcionar la regla de
derivación
Esto mantiene el modelo más compacto: es "no redundante"
Foreign keys
Tener en cuenta el propósito y nivel del modelo

P.ej: un modelo de alto nivel utilizado para extraer el modelo de Dominios no
incluye atributos
Ejercicio
W orker

-date_of_birth

/ -age
-birth_date Job
Grade

Ball Point Pen
-has_top
-ink_color
/ grouped by
groups
* * *

allocated to * currently holds 1
Job Title
Employee

-service_date

0..1

-next_review_date
Parent Of
-previous_manager_name[*] from
1..*
descended
Employee
-vacation_days 2
-address
-number of employees
-name
OK… pero todas las entidades necesitan un identificador

Redundante o incorrectamente asignado
/ Derivable. Funcionalmente dependiente.
Tres niveles de detalle
Elemento Modelo E/R de Alto Nivel Modelo de Dominio Modelo de Servicios

Entidad Los principales todos todos
Definicion (texto) yes, ideally todos todos
Atributos not needed most todos
Relaciones Relaciones entre entidades todos todos
incluidas
Nombre de Relación y util si si

Cardinalidad
Identificadores yes si
Optionalidad de Attributos no esencial si
Definicion de Atributos y Sólo si el significado No si el significado
Relaciones no está claro es obvio
Indicador de Derivacion “/” si, importante si, esencial

on atributos y relaciones
Ambito Organización 1 Dominio 1 Servicio
Modelización E/R
Resumen
El Modelo E/R es esencial para el Plan de Servicios
Se usan dos niveles de modelización

Alto – para encontrar los Dominios
Detallado (para cada dominio) – para encontrar candidatos a “core business services”
de Servicios:
Modelización SOA
Identificación de Dominios (Business Domains)

Identificando Dominios
Para que identificar Dominios
Una técnica para identificación de Dominios
Service Domains
Dominios Verticales y Horizontales
Donde estamos
Business Definir Políticas de Planificación y Aprovisionamiento Modelo de

Modeling Dominio
e
Realizar acciones de Priorización (Triage) usado aquí
Model E/R Alto Nivel Decidir Ambito y Planificar Iteraciones
Obtener Modelos Detallados de Negocio
Identify Business
Domains
Refinar Políticas
Identificar Otros Servicios y Dependencias
Modelo de Dominios
Identificar Unidades de Automatización y Depen.
Diseñar Arquitectura de Despliegue de Servicios
Publicar la nueva Release del Plan de Servicios
Dominios
Particiones lógicas de una empresa consistentes en un conjunto de recursos

de negocio, mas los procesos de negocio que actúan sobre dichos recursos.
Ejemplo:
MANUFACTURING
DISTRIBUTION
SUPPLY
ASSETS
MARKETING FACILITIES
CUSTOMERS
FINANCE
HUMAN RESOURCES
Resources Business Processes

Empleado Contratación
Puesto de Trabajo Fidelización de Empleados
Departamento Cambios Organizativos
Fondo de Pensiones Gestión del Fondo de Pensiones
¿Por qué molestarse para encontrar dominios de negocios?
El Plan de Servicios es una tarea compleja.

Subdividir la organización en Dominios permite la planificación de la actividad a
llevarse a cabo cada vez en un dominio
Los Servicios de un dominio pueden compartir políticas y semántica

Esto hace que sean más fáciles de utilizar, más fácil de construir
Los Servicios para un dominio distinto podrían seguir otras políticas
Consejo: Los Servicios de un dominio no deberían acceder directamente a

los servicios de otro dominio
Esto hace que sea más fácil de administrar, probar y mejorar los servicios de un
dominio
Las fronteras de un dominio son seleccionadas para minimizar las dependencias
entre dominios
Los servicios inter-dominio han de ser delegados a un nivel superior de servicios
‘compuestos’
Técnica de Identificación de Dominios– Paso 1
Comenzar con un diagrama de alto nivel de modelo E/R de la organización

entera
.. O cualquiera que sea dependiendo del alcance del Plan de Servicios
No es necesario incluir todas las entidades, sino encontrar las
principales
Es una buena práctica realizar una definición de cada entidad
No es necesario incluir atributos
No es necesario incluir identificadores y restricciones
Técnica de
Identificación
122 de Dominios www.swassociatesint.com
Modelo E/R de Alto Nivel
agrees Supplier Stock
Supplier
Contract
Shipper
receives Truck
governs involves is of houses
Stock used for
makes
Purchase buys
Order Product
Warehouse supplies Outbound Delivery
results in
Proposed relates to appears in
Customer fulfilled by
Offering Sales Complaint
has predicted
Forecast
receives Vendor
advertises Sales
made by Order
is for refers to places placed with
Equipment
Customer
invites buys
Campaign includes Promotion responsible for
Equipment or
assigned to Consumables
Product maintains
Catalog used to access makes Purchase
applies to Territory located in
for Building
Service
from Contract
Channel assigned to IT
Payment includes contains Equipment
located in
Budget
Room Or
allocated to
Space manages
Organization
Unit
based on responsible for Document
Balance includes cost of owned by
administers Or File
Sheet entered on uses required for
covers Employee
Plan
applies topaid to as allocation of
Pay Check performed by assigned to
takes entry from has trained has access to
enjoys
records Job
Key
Account Performance involves comes with
IT
Técnica de Indicator Process Privilege Capability
Identificación
de Dominios www.swassociatesint.com
Técnica de Identificación de Dominios– Paso 2
Sobre el diagrama dibujar lineas delimitando las fronteras de dominio

Seleccionar fronteras minimizando el número de relaciones que cruzan dichas
fronteras, y maximizando el número de relaciones dentro del dominio
El dominio debería ser un área nombrable de la organización a la que se pueda dar

una definición (no tiene por qué coincidir con una unidad de organización)
Cada entidad debe de estar asignada a un dominio y sólo uno
Todas las entidades deben estar conectadas directa o indirectamente con relaciones
dentro del dominio -> buena cohesión
Los dominios pueden ser muy variables en tamaño. (7 - 20 dominios por

organización)
Técnica de
Identificación
Dominios candidatos
agrees Supplier Stock
Supplier
Contract
Shipper
receives Truck
governs SUMINISTROS
involves is of houses
Stock
Purchase buys
makes used for LOGISTICA
Order Product
Warehouse supplies Outbound Delivery
results in
Proposed relates to appears in
Customer fulfilled by
Offering Sales Complaint
has predicted
Forecast
receives Vendor FACILITIES
advertises VENTAS Sales
MARKETING made by Order
is for refers to places placed with
Equipment
Customer
invites buys
includes Promotion responsible for
Generalización
Campaign
Equipment or
assigned to Consumables
reemplazada
Product maintains
Catalog used to access makes Purchase por una relación
applies to Territory located in
for Building
Service
from Contract
Channel assigned to IT
Payment includes contains Equipment
located in
Budget
Room Or
allocated to
Space manages
Organization
based on
Unit
responsible for Document
TI
Balance includes cost of owned by
administers Or File
Sheet entered on uses required for
covers Employee
Plan
applies topaid to as allocation of
Pay Check performed by assigned to
takes entry from has trained has access to
enjoys
records Job
Key
involves comes with
Account ESTRATEGIA Y Performance IT
Indicator
Técnica de
FINANZAS Process RECURSOS Privilege Capability
Identificación
125 de Dominios HUMANOS www.swassociatesint.com
BP = Business Party
Trucos S = Supplier
C = Customer
Duplicar atributos de Supertipo en cada dominio

Mantener los subtipos en el mismo dominio
BP
- a
- b S C
- a - a
- b 0..1 0..1 - b
S C - c is same as - e
- c - e - d - f
- d - f
Reemplazar generalización con una relación Mover los datos del Supertipo a una
entidad en un Dominio de Referencia
S BP
0..1 1 S C
- c - a
is a kind of
- d - b - c - e
- d - f
- x - x
0..1 0..1
C
- e
1 1
- f Dominio
BP Ref Data
De
-x
Referencia -a
-b
Técnica de
Identificación
¿Porque minimizar conexiones entre dominios?
Es mas eficiente trabajar en Dominios autocontenidos pues:

Los desarrolladores, no interfieren el uno en el otro trabajo del otro
un servicio no puede invocar servicios de otros dominios
dentro de un mismo dominio, los servicios pueden invocar entre sí
La búsqueda de errores y problemas puede ser reducida a determinados dominios
Un dominio puede seguir un conjunto de políticas, y compartir un modelo semántico
al tiempo que permite las diferentes políticas y la semántica en otro dominio
En la práctica no es posible tener dominios totalmente independientes
En un proceso, o una solución de software, se necesitan datos relacionados de
distintos dominios
«use case»
SOLUTION LAYER
Register New Order
1 getFinishedProductPrice( ) 2 addSalesOrder( ) CORE BUSINESS LAYER
FinishedProductService OrdersService
DOMINIO PRODUCTOS TERMINADOS DOMINIO VENTAS

Técnica de
Identificación
Agrupación en Dominios:
Optimizar Cohesión y Acoplamiento
Maximizar Cohesion entre Dominios Minimizar el acoplamiento entre Dominios

Para evaluar la cohesión de un dominio Crear varias propuestas alternativas de
individual, calcular el ratio de cohesión particionamiento y comparar su ratio de
(cohesion ratio) de cada dominio propuesto acoplamiento (coupling measures)
nº de relaciones internas nº de relaciones entre dominios

RCoh = RCou =
nº de relaciones entre dominios nº de dominios
comparar los ratios Seleccionar la propuesta con menor ratio

evitar ratios menores que 1 Comparar el significado de los dominios
para la organización
Ejemplo
Ratio de Cohesión
Dominio A = 6/2 = 3 (bueno)
Dominio B = ½ = 0.5 (pobre)
Ratio de Acoplamiento del Modelo

RCou = 2/2 = 1 (mejorable)
A B
Técnica de
Identificación
Asignar los procesos de negocio para los dominios– Paso 4
Matriz CRU Dominio / Procesos de Negocio
Dominios Recursos Gestión
Marketing Suministro Ventas Logística Finanzas Facilities
Procesos de Negocio Humanos Informacion
Desarrollo de Ofertas C U R R C
Grestión de Campañas C C R U U C
Catálogo C U C R U C
Control de Stocks C U R U C
Ventas y Lgística C C U U C
Contratación Empleados C C C
Fidelización de Empleados U R C
Compras de Consumibles R U C C
Revise Strategic Plan R C C
Un Proceso de Negocio crea (Creates), actualiza (Updates) o referencia (References) instancias

de las entidades del dominio
no es necesario considerar operaciones de borrado
Cada Dominio debe tener al menos un Proceso que crea las instancias de sus entidades
Asignar los Procesos al Dominio donde estos creen la mayoría de los instancias de sus entidades
Si un Proceso crea y actualiza instancias en más de un dominio, considerar la posibilidad de subdividirlo
en sub-procesos que puedan ser asignados a los respectivos dominios.
Cambiar dominios y fronteras, para reducir procesos cruzados de dominio
Técnica de
Identificación
Documentar Dominios – Paso 5
Nombre de Dominio Definición Procesos o Sub-Procesos Entidades

(ratio de cohesión)
Actividades y recursos involucrados en Producción de Catalogos Catalogo de Productos

Marketing identificar nuevos mercados y productos, Gestión de Campañas Campaiñas, Promociones
( 6/5 ) y dominar los mercados con las líneas Desarrollo de Promociones Propuestas, Nueva Oferta
de productos Desarrollo de nuevos productos
Actividades y recursos requeridos para Gestión de mínimos Proveedor, Contratos,

Suministro mantener los niveles optimos de stocks Reposición de Stocks Productos, Stocks,
( 6/6 ) de productos balanceando costes de Aprobación nuevos Proveedores Ordenes de Compra
almacenaje y disponibilidad Negociación de Contratos
Actividades y recursos necesarios para Ventas al por Mayor y Menor Clientes, (+ subtipos),
Ventas procesar pedidos de clientes Ventas a Organismos Públicos Pedidos, Ventas,
( 2/6 ) Gestión de Clientes,
Previsiones de Ventas
Logística Actividades y recursos necesarios para Planificación de Entregas Clientes, Pedidos, Flota
( 2/2 ) la entrega de mercancias pedidas por Rutas, Salidas de Almacen de Vehículos, Ubicaciones
clientes. Preparación de Pedidos
Para cada dominio documentar:

Nombre
Definición de su alcance
Lista de procesos pertenecientes al dominio
Lista de entidades pertenecientes al dominio
Técnica de Ratio de Cohesión
Identificación
Dominios de Servicios Verticales y Horizontales
Los dominios de servicios Verticales soportan dominios de negocio y se extienden
desde la capa de ‘core services’ a otras capas superiores
Los dominios de servicios Horizontales pueden ser útiles dentro de la capa ‘utility
layer’, para agrupar servicios ‘utility’ similares
Financials Customer Supply Chain Sales-To- Sales & Mar- SOLUTION
Package Rel. Mgmt Management Delivery ket Analysis LAYER
ChangeManagement Sales-to-Delivery Process

Improve Org. Structure
RFQ-to-ProductCheckIn PROCESS
Prepare Quarterly Accounts Manage Campaign SERVICE
New Offering Dev.
Customer Lifecycle LAYER
Strategic Review Prepare Sales Forecasts
MARKETING DOMAIN
CORE
BUSINESS
SERVICE
LAYER
STRATEGY & FINANCE SALES DOMAIN
Tax Calculator Commission Calculator UTILITY

Bookkeeping
SERVICE
COMMON REF DATA LAYER
Company Calendar Company Locations Employee Directory
ALGORITHMS
Resource Scheduler Address Formatter Compound Interest Calculator
Servicios de Referencia de Datos
Servicios de sólo lectura (read-only) que generalmente son necesarios para varios
dominios y aplicaciones. Se encuadran como ‘utility services’
Por ejemplo, Directorios de Empleados, Registros de Localidades, Regiones, Sites,
Periodos de tiempo, Unidades Organizacionales, …
MARKETING DOMAIN
CORE
BUSINESS
SERVICE
LAYER
STRATEGY & FINANCE SALES DOMAIN
UTILITY
SERVICE
COMMON REF DATA LAYER
Company Calendar Company Locations Employee Directory
Identificación de Dominios Resumen
Pasos para la Identificación de Dominios

1. Comenzar con un Modelo dE/R de Alto Nivel
2. Dibujar fronteras de dominios candidatas en el diagrama del modelo
buscar intuitivamente áreas de recursos – no unidades organizacionales
minimizar las relaciones entre dominios
3. Comparar las distintas alternativas propuestas
4. Construir una matriz CRU entidades/procesos para
Asignar procesos de negocio a dominios, o
dividirlos en sub-procesos que pueden ser asignados, o
reajustar las fronteras convenientemente
5. Documentar los dominios
No procede que el conjunto de ‘core services’ de un dominio interactúe con los servicios
del ‘core’ de otro dominio.
Service Domains
Generalmente uno por cada dominio de negocio (Dominio de Servicios “vertical”)
Puede haber otros grupos de servicios de ’utility services’ (Dominio de Servicios
“horizontal”)
Todos los servicios de un ‘dominio de servicios’ comparten políticas (calidad, estándares,
semántica, …)
de Servicios:
Modelización SOA
Ejercicios A1 y A2
Estableciendo Business Domains

Enunciados y soluciones en Volumen B
de Servicios:
Modelización SOA
Identificación de ‘Core Business Services’ y

Dependencias

Identificación de ‘Core Business Services’
Agenda
Conceptos
‘Core Business Services'
Entidades (Business Types) y el Modelo Entidad/Relación
Entidades del Núcleo (Core Business Types) y Entidades de Detalle
Técnica
Un procedimiento para la Identificación de ‘Core Business Services’
Process, Underlying y Utility Services

Se verán en capítulos siguientes
Técnica para la Identificación de ‘Core Business Services’
Esta sesion explica una técnica relativamente mecánica para la identificación de

los ’core business services’
Se obtiene un conjunto de servicios candidatos, y sus dependencias, a partir de

un modelo e/r.
Parte del método es intuitivo, basado en el principio:

"Adquirir un ‘core business service’ por cada entidad principal (‘core’)“
Una técnica formal ayuda a:

Garantizar que nada se paso por alto
Que no se tomen solo las opciones fáciles
Proporcionar una justificación lógica
Donde estamos
Definir Políticas de Planificación y Aprovisionamiento

Business
Modeling
Realizar acciones de Priorización (Triage)
Decidir Ambito y Planificar Iteraciones
Obtener Modelos Detallados de Negocio
Modelo E/R,
Detaillado
Refinar Políticas
Identificar Otros Servicios y Dependencias
Arquitectura de
Especificación
Identificar Unidades de Automatización y Depen. de Servicios
Diseñar Arquitectura de Despliegue de Servicios

Descripciones
de Servicios
Publicar la nueva Release del Plan de Servicios
Core Business Services: el Backbone de la Arquitectura
Ordering Product Stock Control Solution Layer

System Development Application
System (presentation and dialog)
Order
Capability Services
Fulfillment
Stock Management Service (orchestration layer)
Service
Orders Stock Movements

Service Products Core Business
Service Stock Purchases Services
Customers (“backbone” layer)
Service
CurrencyConverter Utility Services

(high reuse layer)
AddressFormatter
Underlying Services
AccountsReceivable Purchasing (not so easy to use)
(from legacy Accounting System) (from highly generic component)
Core Business Services
Los ‘core business services’ son el centro de los recursos TI de la organización:

Por ejemplo:
Employees Services
Products Services
Purchase Orders Services
Customers Services
…
Los servicios guardan registros de cada instancia de cada entidad de que son
responsables
Los servicios proporcionan una visión 360° de cada recurso, y sus conceptos
asociados
Servicios de alto nivel, procesos y aplicaciones pueden compartir cada recurso
Representan operaciones CRUD de dichos recursos
Aseguran un unico punto de operación sobre ellos.
Técnica
PASOS
Paso 1 – Prerrequisitos
Modelo Entidad / Relación no-canónico (Business Type Model)
Procesos de Negocio del Dominio – Descricpciones, diagramas de flujo y CRUD
Politicas
Paso 2 – Determinar los identificadores en el diagrama e/r
Paso 3 – Identificar Entidades del Núcleo (Core Business Types)
Paso 4 – Identificar y asignar Entidades de Detalle (Detailing Types) y Entidades de

Clasificación (Classifying Types)
Paso 5 – Nombrar y revisar los ‘Core Business Services’
Paso 6 – Preparar Descripciones Iniciales de Servicios
Paso 7 – Identificar Dependencias entre Servicios
Paso 8 – Preparar Diagrama de Dependencias de Servicios
Entidad
Un tipo de objeto de negocio, de cuyas instancias la compañía necesita guardar datos en

el sistema de información.
Un objeto de negocio es un recurso del cual se necesita guardar y mantener un registro
Todos las “instancias" de un tipo de negocio se ajustan a la misma definición
Una empresa tendrá muchas entidades, y cada una tendrá muchas instancias
Ejemplos
Materias Curso de
ENTIDADES TANGIBLES Edificio Empleado Primas Formación
Quejas Pedidos Asistencia
ENTIDADES MENOS TANGIBLES de de Presu- a un
Clientes Clientes puestos Curso
ENTIDADES RENACIDAS Linea Plan de

de Rutas
(COLLECTION BUSINESS TYPES) Pedido Entregas
Un Modelo e/r tambien incluye atributos y relaciones (“aflojadas”)

Empleado trabaja en Edificio
-id -dirección
-nombre * 1 -propósito
-fecha nacimie 1
contiene
*
Oficina
-numero
-tamaño
Pasos en la Modelización: Entidades de Detalle y Clasificación
Dominio Pasos de Modelización
Detalle
Dibujar el Diagrama Entidad/Relación
Entidad
Core Segmentarlo en Dominios
Clasificación
? Crear el modelo detallado de los
dominios seleccionados
Detalle
Entidad
Core Clasificar las entidades en tres tipos
Clasificación Core
De Detalle (detailing)
? De Clasificación (classifying)
Dominio
Revisar entidades core
(core business types)
Detalle Revisar cardinalidad
Entidad
Core Reducir acoplamiento
Clasificación
Entidades Core, de Detalle y de Clasificación
Entidades Core (Core Business Type)

Stand-alone, independientes está en
1 1 Dirección
Cliente
Entidades de Detalle (Detailing Types)

Dependientes de una entidad core pertenece a 1
Domicilio * Ubicaciones
Propósito: detallar la entidad Social
Entidades de Clasificación (Classifying Types)

Categorizan o agrupan las entidades asignado a
Curso de * 1 Tipo de
Propósito : diferenciación Formación Curso
Business Type Model produces Core Business Services
Dominio
Detalle «servicio»
Entidad
Core OrdersService
Clasificación
?
Detalle
Entidad «servicio»
Core ProductsService
Clasificación
?
Dominio
Detalle
Entidad «servicio»
Core CustomersService
Clasificación
Ejemplo
Associations
Relaciones
Entidades
Relación
1
Producto Cliente
{sa-id} {sa-id}
* 1 1 {id} 1 1 1 {id}
{id} {id}
1 1..* 0..1 * * 1..*

Grupo Precios de Fecha de
Producto Pedido Dirección
Producto Fabricación Historial
{sa-id} {sa-id}
1 {id} 1 {id}
* *
Identificador Linea de Ubicación

(atributo) Pedido 1..*
Cuando una entidad Por ejemplo, el precio del producto Identificador

tiene identificador identificado por la fecha y el producto (relación)
único, suele añadirse a que está asociado. El identificador
sa (single-attribute), de relación sería {id_fecha}, que no Cuando una entidad tiene un identificador
al nombre del sería identificador único y haría falta que implica una asociación a otra entidad,
identificador {sa-id} {id_producto} para determinar cada suele señalizarse la relación con el {id}
instancia
Categorización de Entidades
Independiente
1
Independiente
Producto Cliente Independiente
{sa-id} {sa-id}
* 1 1 {id} 1 1 1 {id}
{id} {id}
1 1..* 0..1 * * 1..*
Familia Precios de Fecha de Pedido Dirección

{sa-id} {sa-id}
1 {id} 1 {id}
* *
Linea de Ubicación
Pedido 1..*
Clasifica a
Independiente
Producto
Categorización de Entidades
1
Producto Cliente
{sa-id} {sa-id}
* 1 1 {id} 1 1 1 {id}
{id} {id}
1 1..* 0..1 * * 1..*
Familia Precios de Fecha de Pedido Dirección

{sa-id} {sa-id}
1 {id} 1 {id}
* *
Linea de Ubicación
Pedido 1..*
Entidad
Asociativa
Responsabilidades de los Core Services
Responsibilidades del Servicio Dependencias entre Servicios

Operaciones Delegación
CRUD de las entidades core Almacenamiento y recuperación de
Queries: listas, búsquedas, … de datos: puede ser delegado a capas
entidades de detalle y clasificación inferiores
Persistencia de los datos Referencia cruzada

Podría ser delegada Un servicio puede hacer referencia
y actualizar datos cuya propiedad
es de otros servicios
Reglas correspondientes a las entidades
Validacion
Integridad
Cambios de estado del ciclo de vida
… sujetas a políticas de diseño y de arquitectura …

Un ‘core business service’ por cada ‘entidad core’
«core» 1 «core»
Producto Cliente
* 1 1 {id} 1 1 1 {id}
{id} {id}
1 1..* 0..1 * * 1..*

«classifying» Precios Fecha de «core»
de Pedido Dirección Historial
Familia Producto Fabricación
1 {id} 1 {id}
* *
Linea de Ubicación
Pedido 1..*
«servicio»
«servicio» Lineas Pedido «servicio»
Productos Clientes
Independencia de Servicios
Cuanta dependencia?
Ninguna (Independiente)
Operaciones sencillas –
functionalidad limitada
Alta reutilización
Complejidad en consumo
servicio / aplicación Servicio Servicio Servicio
Productos Pedidos Clientes
Limitado (Acíclico)
«service domain» Cadena de Suministro (Supply Chain)
Operaciones mas potentes
Más fácil de usar
Puede ser complejo de
construir y mantener
Completo (Cíclico)
Alta complejidad
Baja reutilización
Arquitectura de Servicios por Capas
Business Retail
Manage Capital Adequacy Loan Application Loan Application
Customer Financial
Aggregate Risk Profile Portfolio Visibility
Risk Service Loans

Compliance Customers
Products
Standard Calculations
Product Rules Engine
Credit Check
Regulatory Framework
Resumen
Modelo Entidad Relación Modelo Entidad Relación

(Alto Nivel) (Detallado)
Ambito Ambito
Organización o Dominio Dominio o Proyecto
Contenido Contenido
Entidades Primarias identificadas y descritas Todas las entidades identificadas y descritas
Relaciones Primarias Todas las relaciones
Identificación y diferenciación de atributos Todos los atributos
Identificación del Servicio Especificación del Servicio
Arquitectura de Servicios Especificación de Servicios
Resumen de los pasos de la Técnica
1. Prerrequisitos:
Modelo Entidad/Relación del Dominio
Proceso de Negocio del Dominio – descripciones, diagramas + CRUD
Politicas de Diseño
2. Marcar los Identificadores sobre el diagrama del modelo
3. Identificar Entidades Core
4. Asignar entidades de detalle a entidades core
Decidir emplazamiento de entidades asiciativas
Decidir entidades de clasificación
5. Proponer Servicios Core (Core Business Services)
Agrupar entidades alrededor de entidades core
Refinar la propuesta
6. Preparar Descripción Inicial de Servicios
6a. Considerar generalización de entidades
7. Identificar Dependencias entre servicios
8. Preparar Diagrama de la Arquitectura de Especificación de Servicios
Tratar de reducir dependencias
Conforme a las políticas de diseño
9. Identificar Utility, Underlying and Process Services SESIONES POSTERIORES
de Servicios:
Modelización SOA
Identificación de Core Business Services y Dependencias
Ejercicios B1 y B2
Enunciados y Soluciones en Volumen B

IDU20091026-27 SOAINT DSA v9 - Es

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

IDU20091026-27 SOAINT DSA v9 - Es

Cargado por

Copyright:

Formatos disponibles

www.swassociatesint.

Independent Guidance for

Asegurar que los servicios que se provisionen soportaran:

Una arquitectura débilmente acoplada, de modo que los servicios sean

Integración de sistemas – incluyendo procesos de negocio

Reutilización e integración de los “legacy systems”

Uso de “commodity services” cuando sea apropiado

Compartir servicios cuando sea apropiado

Optimización de procesos e innovación …

Para promocionar el alineamiento y la coherencia entre IT y el Negocio

Para prevenir la anarquía de Servicios

Para proporcionar una estructura por capas que asegure:

La Planificación de Servicios es un esfuerzo adicional al proyecto

Software Associates ha desarrollado un proceso metodológico que:

Identifica el Portfolio de Servicios

Diseña una Arquitectura de Servicios

Define o adopta Políticas

Emite un Plan de trabajo

Ambito Organización Ambito Proyecto

Un proceso dentro de la Arquitectura Un proceso dentro de una solución concreta

Los Servicios del Nucleo (core business services) corresponden a un conjunto de

A continuación, identifica Servicios de arquitectura en otras capas que

El Plan no identifica todas las operaciones

Un Enterprise Plan puede llegar a ser muy grande construcción incremental

1. Introducción 2. Políticas 3. Expectativas 4. Estructura d 5.1 Arquitectura de 6. Programación

4. Enfoque de la Transición APENDICE D

El Plan podría ser mantenido en un Repositorio, conjuntamente con

ARQUITECTURA de IMPLEMENTACION Orders

Arquitectura y Diseño Aprovisonmiento

Diseño Arqu. de la Instalación de la

Plan de Adopcion SOA

Acuerdo sobre el Ambito del Plan de Servicios

Modelos de Definir Políticas de Planificación y Aprovisionamiento

Modelo de Decidir Ambito y Planificar Iteraciones

Obtener la aprobación del Plan Incremental

Publicar la nueva Release del Plan de Servicios Plan de Servicios

Un Enterprise Plan cubre una organización completa

El punto clave es:

Nivel Ambito de la Arquitectura Ventajas Desventajas / Retos

Desarrollo de Control de Solution Layer

Servicio Capability Services

Servicio Movimientos de Stock

Conversor de Moneda Utility Services

Particiones lógicas de una empresa consistentes en un conjunto de recursos

Resources Business Processes

Process Process replaces

& Cargo TRANSPORTATION SHIPMENT

Shipment SUPPY Airports, Seaports, GELOC,

CONTRACTING CUSTOMERS FACILITIES ORGANIZATION

UNDERLYING SERVICES INTERFACE METADATA REPOSITORY

LOGICAL DATA MODEL

SSSS REQUISITION ITEM

Los servicios se identifican desde los Dando lugar a la Arquitectura de Servicios

Definición de Políticas para la Planificación y

Independent Guidance for

Las Políticas del Plan de Servicios

Idealmente, las Políticas deberían estar

La definición de Políticas es importante

Significan “Una estrategia o directiva definida independientemente que regula como

Algunas políticas son obligatorias, otras son solo recomendaciones.

Tácticas de consumo de Servicios Tácticas de priorización (Triage)

Tácticas de abastecimiento de Servicios Prácticas de desarrollo para SOA

Tácticas de Planificación de Servicios Organización de desarrollo para SOA