Blog de Jaime Cid

sábado abril 14, 2007

Resumen Seminario SOA

Realmente interesante el Seminario SOA de SoftwareAG Institute en el que he tenido la oportunidad de participar como ponente invitado. Al final todo un éxito, unas 45 personas, frente a las 20 previstas inicialmente. El ver el tema de SOA desde diferentes ángulos es desde luego enriquecedor, y conocer las experiencias reales de Mapfre Caja Salud, Endesa, y GISS (Gerencia Informatica de la Seguridad Social) más todavía.

He salido con algunas ideas más claras que voy a intentar resumir.

Los 4 pilares básicos de SOA se pueden considerar que son Tecnología, Metodología, Gobierno y Gestión del Cambio, que coinciden con las 4 Ps (Platforms, Practices, Processes, People) que aparecen en el documento de guía SOA de Sun. Por tanto en la evolución hacia SOA, la tecnología, en general el Software de plataforma SOA, es algo muy importante pero no suficiente. Mi trabajo suele estar concentrado en conocer muy bien la tecnología, así que he tenido la oportunidad de ampliar las otras áreas. En este punto de los 4 pilares coincidían además tanto Enrique Bertrand (SoftwareAG), como Leire Bastida (ESI) o David Pascual Portela (INDRA).

Los dos acrónimos clave en SOA, especialmente en el área de tecnología son ESB (Enterprise Service Bus) y BPM (Business Process Management). Hay otros, pero estos dos parecen haber consolidado las dos categorías principales de soluciones de Software de Infraestructura SOA. Javier Cámara supo transmitir muy bien donde encaja el ESB dentro de una arquitectura lógica de referencia. Más allá de estas dos categorías, el resto de categorías como BAM (Business Activity Monitoring), Portal, BPEL (Business Process Execution Language), BRE (Business Rules Engine), B2B (Business to Business), ETL (Extraction Transform Load) son complementarias y suelen estar englobadas en las SOA Suites de los grandes proveedores.
La evolución hacia SOA es en la mayor parte de los casos una evolución conjunta de los departamentos de negocio y los de sistemas de información (TI). Pero claro, el foco de interés para los equipos técnicos suele ser el ESB, mientras que el BPM suele serlo para los equipos de negocio. Sólo hay que darse cuenta donde está la B de Business. ¿Se podría implantar un BPM sin tener un ESB? En la evolución hacia SOA lo habitual es empezar creando servicios, muchas veces para exponer lógica de negocio ya existente. Un ESB puede ayudar en esta tarea especialmente en el caso de tener que integrar en la arquitectura múltiples sistemas heterogéneos. En casos simples donde no sea necesario un ESB, se podría implantar un BPM como parte de una arquitectura SOA, pero lo habitual es que sí que sea necesario un ESB, y por tanto el BPM se debería integrar perfectamente con el resto de infraestructura.

En el área de Gobierno SOA (SOA Governance) también existe tecnología, pero generalmente está más próxima a los departamentos de Operación, Explotación, Producción, Sistemas, Seguridad, Metodología o Calidad y más alejada de los departamentos de Arquitectura y Desarrollo. El registro de servicios, generalmente basado en UDDI, suele ser el punto de contacto entre ambos y pieza clave en las soluciones de Gobierno SOA. También hay que considerar en este área las soluciones IAM (Identity Access Management). Es por esto que los proveedores de soluciones de Gobierno SOA sean a veces distintos o complementarios a los proveedores de soluciones ESB y BPM e incluso las propias soluciones de Gobierno de los diferentes proveedores muchas veces son complementarias entre sí. Aun así un buen Gobierno SOA tiene más implicaciones que las meramente tecnológicas.

En la sesión de Gestión del Cambio, David Pascual Portela de Indra, desarrolló los aspectos clave en la evolución hacia SOA. La conclusión más importante es que es necesario la creación de un equipo de Arquitectura SOA desde las primeras etapas, formado por personas de TI y de negocio. Este equipo puede ser construido a partir de perfiles ya existentes, pero desde luego evolucionar hacia SOA sin hacer algunos cambios organizativos o de roles, y por tanto sin contar con el apoyo de la dirección parece muy complicado.

Como siempre, los casos prácticos despertaron gran interés ya que permiten compartir experiencias y entrar en contacto con la realidad. ¿y cual es la realidad? Pues la realidad es que casi siempre nos encontramos ya muchos Web Services, y primeros pasos en la nueva dirección, pero en general las funcionalidades de los ESB y BPM se han construido internamente con la tecnología existente. En los tres casos prácticos de Mapfre, Endesa, y GISS, ya tienen en producción abundantes Servicios Web sobre Servidores de Aplicaciones J2EE y ahora mismo es cuando se está en proceso de decisión de tecnología de ESB, BPM o Gobierno según los casos.
La evolución hacia SOA requiere tener las ideas claras y suele ser un proceso que puede durar varios años. La realidad es que la primera toma de contacto siempre se produce empezando a utilizar Web Services en los proyectos actuales sin adquisición de nueva tecnología. Luego en función de cada caso particular se decide por donde continuar.

Por cierto, las ponencias de Enrique Bertrand fueron excelentes, tanto la de Beneficios que aporta SOA, como la de cálculo del ROI para justificar SOA desde un punto de vista de negocio. Esta claro que si SOA implica adquisición de tecnología y cambios organizativos, se debe poder explicar y justificar. La audiencia del seminario, mayoritariamente perteneciente al área de TI, necesitamos de sólidos argumentos de negocio para justificar estas inversiones y cambios.