Foto: ibm.com

En una presentación de Oracle sobre el gobierno SOA, se muestra una encuesta de Infoworld donde se listan las causas por las que se ha dificultado la adopción de una arquitectura orientada a servicios en la empresa.

Son las siguientes (incluyo mis comentarios):

1.- Falta de gobierno SOA

El 50 % respondió que la principal causa era la falta de gobierno SOA. Ya traté en este mismo blog el tema del gobierno aunque fuese de manera introductoria. También puedes ver los “siete pasos hacia el gobierno SOA” también en este blog.

Según Oracle, el gobierno SOA es (traducción libre):

El gobierno SOA define un marco de actuación ágil y eficiente (capaz de responder en el logro de los objetivos trazados y de dar respuesta en términos medibles) para dirigir y asitir en la consecución de los beneficios de SOA. Hace hincapié en un cambio cultural en la empresa para la adopción de SOA.

2.- Dificultad en la construcción de un roadmap de SOA:

En SOA, las interdependencias entre los servicios se multiplican por varios factores respecto a un diseño tradicional de las aplicaciones. Las aplicaciones departamentales o tipo silo no dependía de nadie (más que de ellas mismas). Que pasaría ahora por ejemplo, si un servicio de Préstamos necesita un servicio de Riesgos para evaluar si se concede o no un préstamo. ¿que pasaría entonces si empezamos a desarrollar los servicios del primero y se retrasan los del segundo? Tendríamos aquí una dependencia difícil de salvar. Esta situación no es rara en absoluto, es bastante frecuente en una empresa y grande y tenemos que aprender a lidiar con ella.

Por lo tanto, una de las decisiones más difíciles que tenemos que tomar, es organizar el roadmap de los servicios que vamos a implementar, donde se recoja qué servicios, en qué orden y quien es el responsable de hacerlo.

3.- Rendimiento y fiabilidad:

Estos son unos de los grandes cuestiones de una implementación SOA. Aunque sea de manera intuitiva, yo creo que a todos nos preocupa el tema del rendimiento cuando vemos la cantidad de componentes, servidores, invocaciones, “saltos” de un servicio a otro, etc. etc. La conversión de mensajes XML en objetos, vuelta al XML, etc. etc.

Es innegable que una implementación SOA compleja (con servicios web, ESB, UDDI, etc. etc.) tiene un impacto en el rendimiento. Sin embargo, la cuestión es ¿podemos asumirlo? ¿podemos asumir que un programa puede necesitar un 30% más de CPU?

Evidentemente todo desarrollo debe tener sus pruebas de stress que garanticen un desempeño mínimo. Además hay que tener en cuenta que el coste de CPU y memoria van bajando contínuamente gracias a la conocida ley Moore.

Hace tiempo, y prueba de que los arquitectos tenemos que cambiar el chip a este respecto, es un PDF que leí hace tiempo de la empresa EMC (fabricante del gestor documental Documentum). Cuando se refería a SOA, decía más o menos: “hasta ahora cuando veíamos que desde un servicio llamaba a otro lo veíamos como como un “coste”, ahora debemos ver cada una de estas invocaciones como un valor añadido”. La verdad es que esto tiene miga.

4.- Estándares incompletos o inmaduros:

más que cuestión de estándares inmaduros yo creo que la cosa puede estar más bien en productos (middleware) inmaduros. La verdad es que mi experiencia con los nuevos productos de desarrollo y servidores no es buena. Da la sensación de que estos productos (incluso de los principales fabricantes) están bastante verdes, tal vez porque no pueden responder con la suficiente rápidez a la aparición y posterior implementación de estos estándares.

5.- Aspectos de seguridad no resueltos

En este aspecto mi opinión es que lo que se necesita para implementar la seguridad en los servicios (al menos en los servicios web) está resuelta. Esto no quiere decir por supuesto que sea sencillo hacerlo.

Con el estándar WS-Security tenemos una forma de propagar las credenciales del usuario para la autenticación. También nos ofrece la confidencialidad de partes o todo el mensaje, la firma del mismo, etc.

6.- Falta de una infraestructura de servicios

No hay duda que hay una falta de infraestructura en determinados aspectos, sobre todo en la gestión de servicios. Por poner varios ejemplos:

Monitorización de servicios: ¿quién invoca a un servicio? ¿con qué tiempo de respuesta? ¿cuanto tiempo ha estado caído un servicio?

Análisis de impacto: ¿qué pasa si cambio un servicio? ¿quién se verá afectado?

Monitorización de errores: Debería haber un control de errores homogéneo

7.- No hay una arquitectura de referencia

Los grandes fabricantes de software, como IBM y Oracle, tienen perfectamente definida su arquitectura de referencia SOA. Por este aspecto no nos deberíamos preocupar. Lo que sí hay que tener en cuenta es que estas arquitecturas de referencia suelen ser bastantes complejas y dirigidas a empresas muy grandes y con un gran alcance. Es decir, en la mayoría de las ocasiones es un bocad demasiado grande para empezar. Habría que reflexionar al principio y pensar realmente qué es lo que necesito de esta gran arquitectura de referencia. En los primeros momentos y quizás también a medio plazo podríamos usar una simplificación de la misma.

8.- Dificultad en determinar donde o cómo empezar

No hay que ver la adopción de SOA como un todo. Como dicen los expertos “hay que empezar pequeño”. Lo mejor es identificar una funcionalidad no crítica, con pocas dependencias para empezar a rodar este cambio de mentalidad, herramientas, estándares y sobre todo forma de hacer las cosas que es SOA

9.- Identificar una nueva aplicación o servicio a construir

Como comentaba en el punto anterior, este es un aspecto que hay que tener muy en cuenta. Por dar un consejo, quizás se podría empezar por uno o varios servicios de consulta (no serían críticos para el negocio) y a ser posible que vayan a ser invocados desde diferentes canales (red de oficinas, internet, tarificadores, call center, etc.). La multicanalidad y la reutilización de un servicio (se desarrolla una sola vez y se reutiliza una y otra vez) es la forma más clara para que la gente de negocio pueda ver en la práctica las ventajas de SOA.

10.- Financiación:

Éste es uno de los más peliagudos, aunque está en el último lugar en la encuesta. Quizás lo más difícil sería convencer a la gente de negocio que confién en una futura reducción de costes y time to market, aunque a corto plazo el coste de los desarrollos se va a incrementar. Es sembrar ahora para recoger después.

Conclusión:

Hay que tener especialmente en cuenta la cuestión del gobierno SOA. Éste es un aspecto que tal vez no se aborda desde el primer momento: si no tenemos nuestro gobierno SOA, tendremos nuestra anarquía SOA.

Comparte esta entrada:

Share