La identificación de los servicios útiles para el negocio es una de las tareas más difíciles en el diseño de una solución basado en SOA. Hace ya algún tiempo, en este mismo blog, trataba el asunto en esta entrada ¿cómo identificar los servicios de negocio en SOA? y en esta otra a vueltas con la identificación de servicios en SOA.

Nunca está demás tener en cuenta alguna técnica o consejo que nos ayude en el análisis de la solución y que nos facilite el «descubrimiento» de los servicios que formarán parte de nuestra aplicación.

Al hilo de esto, hay una interesante reflexión en esta página dónde se discute sobre cuál es la mejor aproximación en el diseño de una solución SOA. Una aproximación Top-Down o descendente u otra del tipo Bottom-Up o ascendente.

Bottom-up o análisis ascendente, lo mejor para empezar aunque con peros

Parece que todo el mundo está de acuerdo que el enfoque ascendente es lo mejor para empezar, ya que se consigue rápidamente un gran número de servicios.

Los que están a favor del enfoque ascendente, defienden que de una manera rápida se pueden ensamblar una gran cantidad de servicios  a partir de servicios ya existentes o de la rápida exposición como servicio de lógicas de negocio ya existentes en el backend de la empresa.

Sin embargo, los detractores de este enfoque indican que se corre el riesgo de llegar a una situación que de manera muy gráfica se  llama ABOS (a buch of services) o lo que es lo mismo, un montón de servicios sin mucho orden ni concierto.

Además, si se sigue un enfoque ascendente, probablemente se tendrán muchos servicios duplicados y lo que es peor tener una conjunto de servicios (más o menos organizados) que reflejan lo que tienes actualmente, no lo que los clientes necesitan.

Según el artículo, la elección de un enfoque u otro dependen de la relación entre IT y negocio. En esto me temo que queda mucho trecho que recorrer, ya que en el caso de que Negocio haya oído hablar siquiera de SOA, seguro que es para decir que es cosa de técnicos. Este es uno de los mayores problemas que tenemos que sobrellevar para adoptar SOA en la empresa: lograr que SOA no se vea como una cosa de los «frikis» de IT, y para ello ni siquiera ayuda las siglas de SOA.

Ni uno ni otro, la virtud está en el justo medio

Como siempre, la virtud está en el justo medio y la tercera vía es hacer las dos aproximaciones aunque con una matiz:

  • Por un lado tenemos que SOA no es un concepto técnico, es un estilo de arquitectura, de diseñar u organizar los servicios de negocio de la empresa.
  • Sin embargo el estándar de web services, la forma más común de implementar SOA, sí que es una es una cuestión técnica (y no precisamente trivial).

Por lo tanto, lo mejor es realizar primero un análisis descendente, viendo lo que el cliente necesita y por tanto teniendo en cuenta las necesidades de negocio (perspectiva de negocio).

Por otra parte, desde el punto de vista técnico seguir un enfoque ascendente para partir de lo que se tiene (perspectiva técnica). Por supuesto, con la vista puesta en proporcionar servicios compuestos (de más alto nivel) que respondan a las necesidades del cliente.

Comparte esta entrada:
Share