SOA Governance, Enfoque Practico

SOA Governance
(Administración SOA)

Luis Alberto Espinoza Bustamante

1

Agenda

SOA Governance
Algunas Problemas por Falta de Governance
Quien: SOA Office (y Centro Competencia SOA)
Que: Plan Inicial
Como: Procesos de Governance, Herramientas de
Apoyo.

2

SOA Governance
Es una estructura de administración que permite cumplir con
éxito el proyecto de implementar SOA en una empresa, y
lograr los objetivos de negocio propuestos.

Esta estructura contempla los niveles estratégicos, tácticos, y
operacionales.

Define el “Modelo de Governance”:
– Que Hacer: El plan global de proyecto SOA de la Empresa, define el “SOA
Roadmap”(Plan de Ruta SOA).
– Quien lo Hace: La estructura organizacional (los grupos de trabajo), define la
“SOA Office”.
– Como Hacerlo: Los procesos (procedimientos) de administración, las normas,
.
– Como Medirlo: Las métricas para medir el éxito

Contempla lo necesario para un planeamiento y dirección
efectivos de este nuevo esquema de trabajo.

3

Importancia del SOA Governance
“SOA Governance ya no es una opción, es un
imperativo, sin esta administración no se logra
el retorno de la inversión, y todo proyecto SOA
estará en riesgo”. (Gartner)

“Un SOA mal implementado esta por debajo
del 35% de reutilización” (Gartner)

“El 80% de la falla de los proyectos de SOA
esta en la carencia de mecanismos de
Governance.” (Gartner)

El fundamento principal de SOA, es la
reusabilidad, si no se logra, entonces no se
obtienen los beneficios de la flexibilidad y
menores costos de mantención, luego no se
cumple ROI.

4

Características Servicio SOA:
Que es y Que no es un Servicio
ES: NO ES:
Una Pieza de Lego: sirve para crear Una Pieza de Rompecabezas: sirve
varios juegos distintos. para crear un solo juego.

Una funcionalidad del negocio. Funcionalidad general (no de negocio):
Ej.“dar de alta un cliente”, “validar Ficha Ej. “validar Rut”
de un Cliente”, “consulta pólizas vida de
un cliente”
A la medida (no reutilizable): solo sirve
Reutilizable: se puede utilizar en otros para un proceso de negocio, o una
procesos de negocio. Ej. “consulta aplicación. Ej. “consulta pólizas por id
cliente”, “consulta pólizas grles de un Sistema Operacional”
rut”
Propietario (no estándar): solo se
Estándar: independiente de puede usar bajo una tecnología. Ej. “una
plataforma, se puede integrar a clase Java”, “un Webservice que
distintos tecnologías. Ej. Estándar devuelve dato Visual Basic”
“Webservices”, WS-I estándar de
interop. Rígido: fuerte impacto de los cambios.
“WebService con entrada en campos
Flexible: impacto de los cambios es largo fijo”.
menor. “XML” marca la diferencia.

5

QUE: SOA en la Empresa
Usuarios

Aplicaciones SOA
(Portal)

Plataforma Portal
Comercial

Servicios Presentación
(Portlets)

Calendario/ Agenda Lista de Pendientes Noticias Cartera Clientes

Procesos de Negocio
(BPMS)

Proceso Negocio A Proceso Negocio B

Servicios
(WebServices, Obtener Obtener Obtener Obtener Agregar Obtener Obtener Agregar
ETL) Mes Tareas Ficha Productos Propuesta Resumen Cartera Cliente
Calendario Agente Cliente Vida Cliente Noticias Ejecutivo

Sistemas Operacionales

CRM Sist. ERP Sistema SAP SalesForce 6
Operacional Externo

Algunos Problemas por falta de Governance?

Se han implementado servicios con falencias en SOA, que
no aseguran reutilización o flexibilidad.
No esta definido quien diseña el Servicio.
No hay instancia de revisión del diseño del Servicio.
Tenemos repositorios de aplicaciones pero no de
componentes.
No existe un registro (informativo) de los servicios.
Cada proyecto crea sus propias herramientas, o librerías, y
estas no quedan documentadas, y accesibles para los
demás.
Las experiencias buenas o malas de los proyectos quedan
en el proyecto.
Tenemos procedimientos para manejo de aplicaciones, pero
no a nivel de componentes reutilizables.

7

Algunos Problemas por falta de Governance?

Es muy desgastador comprometer a un Jefe de Proyecto en
SOA, típica respuesta: “La aplicación la puedo hacer sin
servicios, y a mi me evalúan por hacer aplicaciones, y a mi
cliente no le interesa si yo lo hago con servicios, luego que
gana mi Proyecto”.
No está la interiorizada la idea de compartir, o de pensar en
los beneficios a mediano plazo.
No hay una definición clara para asumir los costos iniciales
de implementar SOA.
Se ha propuesto catálogos completos de servicios,
soluciones del tipo “BigBang”, no recomendado por SOA.
Se tiene la idea de que solo basta con desarrollar
WebServices para cumplir con SOA, no importa el diseño
del servicio, no se toma en cuenta el tipo servicio (de
negocio o de información.

8

Quien: SOA Office

El primer paso en el SOA Governance
es constituir los equipos de personas
que definirán el “Plan” (Roadmap), y SOA Office, o SOA COE (Center of
Excellence)
definirán el modelo de Governance.
SOA PMO (Project Management Office) SOA PMO
Equipo a Nivel Estratégico encargado (Project Management Office)

principalmente de tomar y validar las
decisiones SOA.
SOA CC (Center of Competence) SOA Project Team
Equipo a Nivel Táctico trabaja codo a
codo con la PMO, y es la autoridad de
arquitectura y diseño de SOA. SOA CC
SOA Project Team (Competence Center)

Son los equipos operativos
encargados de desarrollar y
mantener las soluciones SOA.

9

Quien: SOA PMO

Este equipo debe:
– Definir los principios SOA.
– Respaldar las definiciones del Centro de Competencia SOA Office, o SOA COE (Center of
Excellence)
(SOA CC).
– Priorizar los Procesos de Negocio (BPMS) y los SOA PMO
Servicios SOA. (Project Management Office)

– Priorizar y Aprobar los Proyectos SOA.
– Asegurar que la estrategia SOA este alineada con la
estrategia de negocio
– Revisar el desarrollo del Plan SOA (revisar métricas).
– Determinar la inversión en SOA (determinar SOA CC
presupuestos). (Competence Center)

– Presentar y Promover los estándares SOA.

10

Quien: SOA CC

Este equipo debe:
– Definir los estándares SOA.
– Definir los criterios de Evaluación SOA. SOA Office, o SOA COE (Center of
Excellence)

– Mentor de Arquitectura y Metodologías.
– Mantener el catálogo de componentes SOA (Procesos SOA PMO
(Project Management Office)
de Negocio, Servicios SOA).
– Aprobar los nuevos componentes SOA, y los cambios.
– Asegurar que se cumplan los estándares.
– Mantener la arquitectura de referencia SOA.
– Proveer las herramientas para facilitar SOA.
SOA CC
– Determinar el dominio (dueño) de los componentes (Competence Center)
SOA.

11

Quien: SOA Project Team

Este equipo debe:
– Desarrollar y Mantener los proyectos sobre
SOA.
– Desarrollar y Mantener los Procesos de
Negocio.
SOA Office
– Desarrollar y Mantener los Servicios. SOA Project Team
SOA PMO

SOA CC

12

Quien: SOA Project Team

13

Roles Arquitecto SOA
Arquitecto SOA
Responsabilidades
• Mediador entre negocio y tecnología.
• Mas que de la estructura del sistema (edificio), se preocupa de la
integración con los otros sistemas (cityplanner) o con los componentes
existentes.
• Realiza la adaptación desde negocio a TI, traduce desde conceptos y
componentes de negocio en componentes y conceptos TI.
• Asegurar que los “Ingenieros de Servicios” no sobreexpongan
funcionalidades como Servicios (cualquier cosa se puede publicar como
WebService).
• Esta encargado del modelo del proceso integrado (con definición de los
componentes TI asociados), y del modelo de los servicios.

Colabora con
• Arquitecto Software
• Jefe de Proyecto
• Analista de Negocio
• Diseñador de Procesos
• Diseñador de Servicios
• Toolsmith

Habilidades Requeridas
• Arquitecturas generales TI, J2EE
• WebServices, SOAP, XML, WSDL
• Estándares y Buenas Practicas (WS-I)

Herramientas de Apoyo
• Modelador de la suite BPM (leer el proceso)
• Ambiente de Integración de la suite BPM (adecua el modelo según los
servicios y componentes tecnológicos)

14

Roles Diseñador de Flujos

Diseñador Flujo de Proceso
Responsabilidades
• Modelamiento Procesos de Negocio
• Ensamble de servicios en procesos.
• Investiga las Posibilidades de Orquestación de Servicios (composición de
servicios)
• Se concentra en los flujos de proceso que soportan a los procesos de
negocio

Colabora con
• Diseñador de Servicios
• Arquitecto SOA

• BPEL
• WSDL

• Modelador de la suite BPMS (leer el proceso de negocio)
• Ambiente de Integración de BPMS (adaptar modelo)

15

Roles Diseñador de Servicios

Diseñador de Servicios
Responsabilidades
• Define los contratos de interface de lo servicio (WSDL)
• Define los esquemas de los mensajes que se intercambian (entrada y
salida)

Colabora con
• Arquitecto SOA
• Ingeniero de Servicios

• Modelamiento de Datos y Funciones.
• Estándares y Buenas Practicas de diseño de servicios
• WSDL, SOAP, XML

• IDE para desarrollo de WSDL y XML.

16

Roles ToolSmith

Toolsmith (Constructor Herramientas)
Responsabilidades
• Diseñar e implementar herramientas que puedan facilitar el desarrollo de
servicios, o proceso de negocio.
• Desarrolla templates.
• Desarrolla librerías de herramientas (APIs).
• Desarrolla prototipos o módulos base que se pueden utilizar en los
proyectos.
• Desarrolla generadores de código, o scripts para facilitar el desarrollo.
• Rescatar y modularizar soluciones implementadas por los proyectos.

Colabora con
• Arquitecto SOA
• Arquitecto Sistemas
• Ingeniero SOA

• WS-I
• ACOS
• J2EE
• WebServices, XML, SOAP
• Conocimiento acabado de los estándares y buenas practicas de desarrollo
de servicios.

• IDE desarrollo
• Ambiente de Integración y desarrollo (de BPMS)

17

Roles Jefe de Proyectos

Jefe de Proyectos SOA
Responsabilidades
• Responsable del equipo del proyecto.
• Define y controla el plan del proyecto.
• Determina la estructura de trabajo.
• Se preocupa de los procesos agregados (compuesto por otros servicios)

Colabora con
• Proveedores de Servicios
• Usuarios de Negocio
• Arquitecto SOA
• Arquitecto Sistemas

• Debe planificar en ciclos de entrega mas pequeños.
• Debe establecer nuevos modelos de aceptación.

• Monitor de Procesos suite BPM (feedback de la solución)

18

Roles Arquitecto de Sistemas

Arquitecto Sistemas
Responsabilidades
• Líder técnico del proyecto.
• Realiza el diseño lógico y físico (estructura) de la solución, y sus
componentes.
• Se encarga de los requerimientos de servicio no funcionales
• Mantiene el modelo del proceso y de los servicios (durante el desarrollo
del proyecto).

Colabora con
• Jefe de Proyectos
• Arquitecto SOA

• Arquitecturas generales TI, J2EE
• WebServices, SOAP, XML
• Estándares y Buenas Practicas (WS-I)

• Integrador de la suite BPM (adecua el modelo según los servicios y
componentes tecnológicos)

19

Roles Ingeniero de Servicios
Ingeniero de Servicios
Responsabilidades
• Desarrolla los servicios (implementa lógica del servicio)
• Desarrolla los módulos cliente que consumen servicios
• Asegurar que los servicios están ajustados a los estándares y buenas
practicas.
• Implementa las interfaces de servicio (WSDL) definidas por el rol
“Modelador de Servicios”
• Integración de los sistemas operacionales.
• Documentación de Código.

Colabora con
• Arquitecto Software
• Jefe de Proyecto
• Modelador de Servicios

• Debe ser uno de los roles mejor equipados de SOA
• WebServices, SOAP, XML, WSDL
• Estándar WS-I
• Conocimiento de los estándares y buenas practicas de desarrollo de
servicios.
• Programación J2EE o .NET
• WS-Security

• Integrador de la suite BPM (integra los servicios a los procesos)
• IDE desarrollo servicios (WebServices) y de publicación (deploy)
• Generadores de WebService y Generadores WSDL to Java.

20

QUE: Plan Inicial

Definir los principios SOA.
Definir el Plan SOA.
Definir los Procesos de SOA Governance.
Adecuar y asignar los roles del “SOA Project Team”, y del “SOA
Office Posterior”.
Definir el primer Proyecto, primeros Procesos y primeros Servicios
a implementar.
Determinar el esquema de presupuesto (manejo costos) para el
primer proyecto bajo SOA-BPMS, y/o para los proyectos que
vendrán.
Implementar la plataforma tecnológica que soportará SOA y SOA
Governance (Servidores, BPMS, Service Registry).
Definir los estándares y buenas practicas SOA iniciales.
Definir los primeros criterios y métricas de Evaluación SOA.
Definir y Ejecutar los planes de capacitación previos.

21

QUE: Nivel SOA Inicial más Común de una
Empresa

22

QUE: Alcanzar Próximo Nivel

23

COMO: Principios SOA para una Empresa

Una solución tecnológica debe ser una solución para los
Clientes (Orientación al Cliente)
– La tecnología debe adaptarse al Negocio y a las necesidades de los Clientes.
– Una solución tecnología debe ser una solución “natural” para los Clientes.
– Un proceso de negocio, una cara al Cliente.
– Solución Tecnológica = Proceso de Negocio.

Mejoramiento Continuo de los Procesos de Negocio (Mejores
Servicios Financieros)
– Paso a Paso, se debe Avanzar.
– La realidad debe ser nuestra retroalimentación.

Un servicio debe servir a mas de un Producto, a mas de un
Proceso (Plataforma MultiProducto)
– Si NO sirve para los demás, entonces NO Sirve.

24

COMO: Procesos de SOA Governance

Procesos Desarrollo Procesos SOA Governance (SOA Office)
TI (Project Team)

Proceso Proceso
Identificacion SOA Revision SOA

Proceso
Desarrollo SOA

Proceso Proceso
Mantención SOA Excepciones SOA

Proceso
Comunicacion y
Promocion SOA

25

COMO: Tablas RACI

Decisión Responsable A Cargo Consultado Informado
(roles) (roles) (roles) (roles)
Que Servicios Hacer
Que Servicios Hacer
Primero
Es Realmente un
Servicio Nuevo, (roles) (roles) (roles) (roles)
Reusable
Quien pagará el
Servicio
Quien sera el dueño
del servicio

26

COMO: Herramientas de Apoyo

BPMS

Registro y Repositorio SOA: Permite guardar, acceder, y
administrar información respecto de los servicios.

Administración de Políticas SOA: Esta tecnología permite
manejar las políticas de seguridad (control de acceso a los
servicios), performance, y niveles de servicio.

Testing y Validación SOA: herramientas para probar servicios y
validar que esten dentro de los estandares.

Administrador de Procesos SOA Governance: permiten
administrar estos procesos especiales de TI y ajustarlos según la
Empresa (WorkFlow prefabricados).

27

Conceptos SOA
Servicio: componentes reutilizables de negocio, con interfaces bien FrameWork: conjunto de herramientas y motor (engine) que permite
definidas, ej. “consultaCarteraAgente”, generalmente se refiere a “Servicio habilitar alguna tecnología.
de Negocio”. AXIS: framework que permite generar Webservices.
Sistemas Operacionales: sistemas legados (heredados) de una empresa, WorkFlow: flujo de trabajo, permite implementar procesos de negocio,
sistemas BackOffice, sistemas aislados orientados a un aspecto especifico pero no soporta actividades automatizadas (servicios).
del negocio. Ej. “PSoft CRM”, “Visual Time”. BPM: (Business Process Management) tecnologia que permite
Servicios de Información: Servicio de mas bajo nivel, encapsula lógica implementar procesos de negocio. Apoya todo el ciclo de vida de un
para acceder a funcionalidades de los sistemas operacionales. ej. proceso: modelar, integrar, ejecutar, y monitorear. Implementación clara
“obtieneClienteCRM”. de SOA, ej. “WorkFlow + WebServices”.
Proceso de Negocio: secuencia de actividades que forma un proceso del BPMS: (BPM Suite) framework que permite implementar BPM y SOA,
negocio, contempla actividades manuales y automatizadas, ej. “Proceso ej. “BEA Aqualogic”, “IBM WebSphere BPMS”.
Cotizar Producto Vida”. Lista Pendientes: portlet que lista las tareas pendientes de un usuario
SOA: (Service Oriented Architecture) arquitectura basada en componentes que participa en un proceso de negocio, lo facilita BPMS.
reutilizables: procesos de negocio y servicios. Estrategia con visión de MQ: (Websphere Message Queues) framework de IBM para
Empresa y de largo plazo. implementar colas de mensajes.
Portlet: sección o módulo gráfico con una funcionalidad bien definida, Java: lenguage de programación orientado a objetos.
servicio de presentación, componente gráfico reutilizable, ej. “Calendario Clase Java: componente funcional programado en Java, esta
en CELA”. compuesto por funciones, y variables.
Portal: aplicación Web compuesta por Portlets, ej. “www.emol.cl”. J2EE (Java 2 Enterprise Edition) framework para implementar
Aplicación SOA: aplicación compuesta de servicios: portlets, procesos de aplicaciones de complejidad empresarial, estandar e independiente de
negocio, servicios de negocio. plataforma (Windows, Mac, Linux, Unix).
XML: (eXtensible Markup Language) estructura de datos basada en tags, ETL: (Extract, Transform, and Load) framework que permite
ej. “<rut>8602345-K</rut>” implementar procesos basados en fuentes de datos (principalmente
SOAP: (Simple Object Access Protocol) protocolo estandar basado en XML bases de datos), permite implementar “servicios de información”.
para implementar servicios. Basado en modelamiento del proceso (simil BPMS pero solo procesos
WebService: implementación de un servicio, basado en SOAP, totalmente Base de Datos). Ej. “IBM Datastage”.
estandar. Deploy: publicar un componente en el servidor web, subir un
Stub: modulo que permite ejecutar (consumir) un WebService. componente a producción, ej. “subir webservice a producción”.
WSDL: (WebService Definition Language) documento XML que describe la
estructura de un WebService, contrato que define como implementar y
ejecutar un WebService.
IDE: (Integrated Development Enviroment) herramienta de desarrollo
integrada, ej. “Visual Studio”, “JBuilder”, “Eclipse”.

28

SOA Governance, Enfoque Practico

Más contenido relacionado

Destacado (20)

Similar a SOA Governance, Enfoque Practico (20)

Más de Luis Alberto Espinoza Bustamante (6)

SOA Governance, Enfoque Practico