telescope-122960_640

Según la teoría, estas serían las metas y objetivos de la aplicación de la orientación a servicios y SOA.

  1. Incrementar la interoperabilidad intrínseca
  2. Incrementar las opciones de diversificaciones de fabricantes de software
  3. Incrementar el alineamiento de negocio y tecnología
  4. Incrementar el ROI
  5. Incrementar la agilidad organizacional
  6. Reducir la carga de IT

Por supuesto, en cada caso los resultados de la adopción de SOA pueden ser muy particulares. Sin embargo, viendo lo que se ha hecho (de lo que conozco) en las empresas hay que decir que lograr estos objetivos es de todo menos fácil.

El primer paso para lograr esto sería aplicar los 8 principios de SOA. Sin embargo, lo primero que habría que decir es que son bastante ignorados y poco aplicados. Hay ocasiones en que no se aplican simplemente por que no se conocen, pero en otras muchas ocasiones se dejan de lado por motivos de tiempo o de “corto-placismo”. ¿Quien se acuerda de que SOA debe aplicarse mediante una estrategia a largo plazo, mientras que las tradicionales aplicaciones silo buscan un beneficio inmediato en el corto plazo?

Muchas veces, es difícil hacer ver que en este momento es necesario aplicar más trabajo y más gasto para tener un beneficio dentro de uno o dos años… en demasiadas ocasiones, lo que cuenta son los resultados para mañana mismo.

Desde luego estas metas y objetivos de SOA daría para hablar largo y tendido. Pero creo que no estaría mal empezar por los 3 que más me llaman la atención.

Incrementar la interoperabilidad intrínsica

Me parece que este aspecto es uno de los grandes desconocidos. ¿Qué significa esto realmente? en primer lugar, para lograr esto tenemos que contar con un inventario de servicios. Un sitio donde se recojan la definición (contrato, SLA e información adicional de negocio) sobre cada servicio de manera que pueda ser encontrada (descubierta) fácilmente por el que quiera usarlo.

Al margen de la implementación técnica de esto, existen varios productos en el mercado, lo que hay que hay que tener muy en cuenta es lo que significa que varios servicios residan en el mismo inventario (puede haber más de uno en la empresa). Hay que ver estos inventarios como dominios funcionales y no sería descabellado tener un inventario de servicios de clientes y otro de “ventas” por poner un ejemplo.

El caso es que todos los servicios dentro de un mismo inventario deben cumplir con las mismas reglas de diseño de sus interfaces (expresados en los contratos) y estas estándarizados. ¿Qué quiere decir esto? pues dicho llanamente que deben utilizar el mismo vocabulario, los mismos tipos de datos, y las mismas reglas de diseño de los contratos. Si nos referimos a servicios SOAP por ejemplo, esto significaría que los WSDL de estos servicios deberían usar los mismos schemas de definición de los datos.

Al usar los mismos datos, se evita la necesidad de hacer transformaciones entre los mismos y se pueden componer varios de estos servicios sin tener que desarrollar y mantener una lógica pesada de transformación de datos (con la mejora del rendimiento en tiempo de ejecución).

¿Cuantas veces se llega a esto? quiero decir, ¿cuantas veces nos encontramos con que los servicios dentro de un mismo repositorio cumplen las mismas reglas de diseño de los contratos y usan el mismo vocabulario?.

Incrementar las opciones de diversificaciones de fabricantes de software

Este es otro de los caballos de batalla que nos encontramos. Normalmente, las empresas tienden a usar las mismas herramientas y el mismo middleware para todos los desarrollos. Evidentemente esta es una decisión discutida y discutible, sobre todo bajo el punto de vista de las nuevas corrientes de los microservicios.

Sin embargo, al menos hasta ahora, parece lógico que las economías de escala facilitan la compra, adopción, formación y desarrollo de servicios con las mismas herramientas por todos los equipos de de trabajo. Esto produce como consecuencia una preocupante dependencia de un fabricante o fabricantes. Está claro que si usamos un ESB de un fabricante, todas las mediaciones que hagamos sobre este dependenerá de este fabricante. No hay un estándar (que se puede usar en la práctica) que realmente nos permita migrar al 100% y sin esfuerzo un servicio compuesto en un ESB de IBM a un ESB de Oracle por poner un ejemplo.

Así pues, lo de lograr la independencia de los fabricantes con SOA se puede hacer, pero muchas veces es posible que nos veamos atrapados en un producto concreto si no ponemos cuidado.

Reducir la carga de IT

Este es otros de los puntos discutidos. En teoría, la adopción de SOA en la empresa nos librará de todo tipo aplicaciones silo, muchas de ellas con funcionalidad repetida y que no puede ser reutilizada en nuevos proyectos debido a que no fueron diseñados para ser integradas en soluciones fuera de sus límites. ¿Quiero esto decir que no nos va a suceder esto con SOA?.

Hay que tener en cuenta, que al menos durante los primeros momentos (y esto pueden ser meses o años) yo diría que la carga de IT más bien aumenta en lugar de disminuir.

En una implementación típica de SOA basada en un ESB por poner un ejemplo, vamos a tener que instalar nuevo middleware, vamos a tener que definir los procedimientos de despliegue, de monitorización y de gestión de incidencias.

Una simple ejecución de una funcionalidad, que en una aplicación silo no salía de su ámbito de dominio y que como mucho implicaba la ejecución en un servidor de aplicaciones y en una base de datos, en SOA se puede multiplicar su complejidad por 3 o por 4 veces fácilmente.

Conclusión

En resumen, no hay que perder de vista una cosa: la estrategia de SOA hay que enfocarla a medio y largo plazo.

Cualquier tentación de obtener resultados a corto plazo nos dará como resultado el que no se cumplen las expectativas. Cualquier enfoque basado en aplicaciones silo de toda la vida superará con creces estas expectativas a corto plazo respecto a cualquier enfoque SOA.

Para que SOA resulte mínimamente rentable a medio plazo nos tenemos que asegurar que los servicios se reutilizan.

Además necesitamos incluir una estructura de gobierno que haga posible por ejemplo el descubrimiento de los servicios disponibles, lograr que estos servicios sean reutilizables, que no se repita la implementación de la misma lógica, etc. Esto implica cambios a todos los niveles que se traduce en mayor complejidad en la gestión de IT.