Proyectos de Integracion SOA-ESB-BPM

Hace poco tuve el honor de participar como ponente en el evento STC Foro http://www.stcforo.com/home.php, para hablar sobre el desarrollo de proyectos de integración, y he querido registrar los puntos generales de mi ponencia en este blog, para contribuir con toda la comunidad. Es necesario decir, que estas recomendaciones provienen no solo de mi autoria, sino de todo un equipo magnifico de venezolanos, que con su profesionalismo y dedicacion contribuyeron con esta ponencia.

La agenda fue muy sencilla, y cubrí los siguientes puntos:

1. Que obstáculos iniciales debe enfrentar una empresa para desarrollar un proyecto de integración?
2. Recomendaciones.
3. Algunas Reflexiones.

Que es un proyecto de integración

Un proyecto de integración es una plataforma tecnológica que sirve para disponibilizar funcionalidades existentes en sistemas heterogéneos, realizando tareas de conexión, adaptación, transporte, transformación, integración, etc, mediante servicios.

Un servicio es un artefacto de software que puede exponer una funcionalidad específica sobre diversos protocolos de transporte y lenguajes.

Que Obstáculos generales debe enfrentar un organización para desarrollar un proyecto de integración?

1. En primer lugar, las organizaciones deben entender el concepto de agilidad operacional: Agilidad es contar con una plataforma tecnológica de servicios que soporte muchos cambios, pero que estos generen poco impacto. Las implicaciones de no poseer una plataforma de integración en una organización son: alta dependencia, alto acoplamiento, poca proteccion tecnológica, grandes impactos ante un reemplazo, información redundante, alta complejidad, etc.
2. En segundo lugar soportar el constante bombardeo de los proveedores tecnológicos de estándares, tecnológias, y especificaciones que tienen como objeto primordial: "Entregar el Santo Grial: la Agilidad Operacional", términos como SOA, ESB, BPM, EDA, MOM son elementos de esa sopa de letras interminable.
3. Una vez que hemos entendido esta sopa de letras, es necesario conseguir un equilibrio donde la evaluación de aspectos como la madurez de la tecnología, comunidad, soporte, open source o propietario, matriz de funcionalidades, pruebas de concepto, etc, son vitales.
4. Otro obstáculo es la constante evolución de las tecnologías, fue en el 2004 cuando los Web services aparecieron en el escenario tecnológico, donde estarán las organizaciones en ese mapa de ruta?
5. Por ultimo, y el mas importante como vender un proyecto de integración. Vender un proyecto de integración no es fácil, a pesar de todas las ventajas que promociona tecnológicamente.

Recomendaciones para afrontar estos Obstáculos:

1. Introduzca un proyecto de integración como un componente más de un proyecto mucho mayor.
2. Utilice pilotos, y no pruebas de concepto o laboratorio, los pilotos tienen un rango mucho mas amplio, el cual nos permite evaluar todos los aspectos técnicos necesarios para exponer servicios.
3. Utilice la vigilia tecnologia y el direccionamiento como elementos claves de la estrategia organizacional.

Tips Generales:

1. Desarrollar servicios no asegura la interoperabilidad: Utilice las herramientas de la Web Services Interoperability Organization (WS-I) para verificar si un web services o servicio es interoperable.
2. El contrato nos hace flexibles, proporcionan agilidad: Eso es lo que por lo común nos venden, la verdad!, depende del modelo de implementación, por lo general; cambios en los contratos rompen las implementaciones de los servicios por lo que generalmente hay que regenerar los proxys (consumidores del servicio).
3. Con frecuencia, los servicios son adaptaciones específicas de las aplicaciones: No es fácil crear servicios reusables, pero se deben contemplar servicios con la interfase lo más ancha posible (mayor numero de atributos).
4. Es necesario establecer un equilibrio entre el conceptual y lo pragmático: aterrice el concepto que verdaderamente necesita.

Algunas Recomendaciones:

1. Aplicar Aseguramiento de Calidad previo a la Construcción de servicios (contratos ajustados, especificaciones claras antes de ir a construcción).
2. Diseñe los servicios con Interfaz “ancha” para potenciar la reusabilidad, Incluso si los servicios son diseñados “a la medida” de un cliente.
3. Codificar con herramientas de 4ta generación es bonito, fácil y aparentemente simple, pero cuando hay problemas, resolverlos es difícil.
4. Roll back: No hacer diseños complejos.
5. Logs,Logs,Logs!!! : Prepare una arquitectura reusable de manejo de Logs con niveles, homogénea y parseable.
6. Olviduese de Logs en base de datos, simplemente no es buena idea.
7. Utilice un manejo homogéneo de errores (Web Services Árbol de Excepciones (Fault)).
8. Incluir como parte del Framework capacidades de Auditoria y Monitoreo.
9. RPC mala idea, Preferir WS Document / Literal en lugar de RPC encoded.
10. Utilize Document Style para los Web Services, es la mejor práctica. No se rompen las implementaciones, orientado a mensajes, y es extensible.
11. Ir a lo Básico, no olvide las herramientas de control de versiones, manejo de incidencias,etc.
12. Viva los Xml*, evite cablear transformaciones, use tecnologías X* para transformaciones de datos en la lógica del servicio.
13. BPM es el futuro.

Reflexiones

• La verdadera integración es de la gente.

• La ausencia de un Arquitecto puede cambiar un Plan.
• La interoperabilidad es importante, utilice los tools de la WS-I.
• Crear estándares, disminuye los riesgos de implementación.
• Existe la practica generalizada de construcción de servicios específicos para los clientes, simplemente Evítelos.
• Pensamos en el desarrollo de software, pero no en como administrarlo y operarlo. No lo dejemos para e final.