Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Análisis y Diseño II
Sesión: 05
gzambranol@usmp.pe
gzambrano@usmp.edu.pe
Semestre: 2011_I
Objetivos:
Presiones Competitivas
Presiones Regulatorias
Sobrecarga de Información
La Fuerza
Cambiante de Trabajo
Imperativos del Negocio, continua…
Presiones Competitivas
SOA
Presiones Regulatorias Ambientes de
Desarrollo
Orientados al
Poder del Cliente Negocio
Web 2.0/
Sobrecarga de Información Rápido Desarrollo de
Aplicaciones
La Fuerza Cómputo
Cambiante de Trabajo Social
Metadatos/
Semántica
La Evolución de la Industria del
Software
Foco en TI
Construir Comprar Componer
Infraestructura de
Sistemas Centrales Negocio
• Pagos corporativos •Automatización de
• Manejo de Quejas Procesos
• Sistema de facturación •SOA y Gobernabilidad
Sistemas de Soporte •Integración
• RH •Modernización
• Nómina • Servicios Web
• CRM • Integración
¿Qué es un Servicio?
¿Cómo lo Obtengo?
¿Qué es lo importante?
– Capacidades distribuidas
– Granular, realizar una unidad de trabajo
– Confiabilidad y calidad de servicio
– Acoplada libremente – ninguna suposición acerca de las necesidades de la otra parte
– Facilidad de uso basada en minimizar las dependencias artificiales
¿Qué es un Servicio?
Business
Business Models and
Business analyst Architect Architect
Analyst requirements
Architect interprets business
Business analyst hands over models and requirements and
Business documentation designs business automation
Traditional projects to architect system.
SOA projects
Business
Business Models and Business
Analyst requirements Analyst Architect
Architect finalizes
Business analyst and architect define Physical design
conceptual design together to ensure
accurate representation of business
logic
Restricciones Arquitectónicas de SOA
Un conjunto pequeño de interfaces simples y ubicuas
Las interfaces deberían estar universalmente disponibles
para todos los proveedores y consumidores
Únicamente se encuentra codificada la semántica genérica
en la interface – la semántica específica de las aplicaciones
en los mensajes
Mensajes descriptivos, es decir, los mensajes no prescriben
ningún comportamiento del sistema , o sólo lo hacen en
forma mínima
Un esquema limita el formato, el vocabulario y la estructura
de los mensajes
Un esquema extensivo permite nuevas versiones de los
servicios que serán introducidos sin romper los servicios
existentes
Definición de SOA
SOA es un estilo arquitectónico cuyo objetivo es lograr un
acoplamiento libre entre los agentes de software
interactuantes.
Consumidor
Servicio Consumidor
Proveedor
Consumidor
SOA: Fundamento de una Arquitectura
Administración y Control
Mainframe SOA
Dependiente Interdependiente
SOA
SOAabarca
abarca99
de
delas
las10
10
Principales
Principales
Prioridades
Prioridadesdede
la
la
Administración
Administración
de
deTITI
Generación de valor con SOA
Arquitectura de Frameworks
Dependiente de Referencia SOA
Tecnología.
Reutilizable Patrones de Diseño
entre Proyectos.
Instancia
Arquitectura
de Referencia. Arquitectura Concreta
Específica de
cada Proyecto.
Arquitectura: Servicios de Negocio
Presentation Business Resources
Session
Facade
Front
Session EIS
Controller
Facade
Session LDAP
Facade
Composite
Session Entity
Facade
Front Composite
Session
Controller Entity
Facade
Session LDAP
Facade
Session
Facade
Front
Session
Controller
Facade
Process Orchestration
Session
Facade
Composite
Session Entity
Facade
Composite
Session
Entity
Facade
Process Orchestration
Session LDAP
Facade
Evolución SOA
Nivel 5 Adopción empresarial de SOA Explotación
Definir estrategia de IT
alineada con objetivos y
Arquitectura metas organizacionales
Empresarial
Gerencia
Mentoring de Workshop de
Proyectos
específico
Valoración de
Arquitectura
Rational
Unified
Process ©
RUP
for
SOA
¿Por qué Gobernabilidad?
Problemas:
•Los sistemas
complejos se rompen
en piezas de servicio
•Los módulos se
conectan de acuerdo a
las necesidades del
negocio
¡SOA no administrado es demasiado complejo!
Fuente: Seminario Básico de BPM - SOA
Gobernabilidad
La Gobernabilidad proporciona:
Autoridades y responsabilidades
Reglas claras y refuerzo de reglas
Transparencia organizacional y técnica
Dominio de los
Aplicaciones
Analistas de
Compuestas
Negocio
Procesos de Obtener Verificar Capturar Revisar Aprobar Iniciar
Negocio Datos Detalles Pedido Pedido Pedido Envío
Administración de Pedidos
GOBERNABILIDAD
Desarrolladores
Dominio de los
Arquitectos y
Integración Datos del
Cliente
Interacción
del Cliente
Historia del
Pedido
Polìtica de
Pedidos
Envío
de Legados
1. Entender el Proceso
3. ¡Gobernar primero!
4. Ignorar la seguridad
5. No estandarizar SOA
6. No pedir ayuda
7. El tamaño cuenta
8. Ignorar la inversión
9. Ignorar su madurez
Ingeniero de métodos
Proyecto
Metodología / Método
Repositorio
Desarrollador
Metodólogo
proyecto
proyecto
Desarrollador
método
método
Ingeniero Metodólogo
de métodos
metamodelo
metamodelo
Especificación
de producto
Nombre: Código Fuente
Soporte: digital
lee
crea
crea
Nombre: Documento de
Especificación de Requisitos
Soporte: papel
DIS_S_05_SOA_GOVERNANCE_RAM_2011_
I.pdf
Revisar:
DIS_S_05_CASO_2011_I.pdf