A medida que avanza la implantación de SOA en una compañía, tarde o temprano, nos tendremos que enfrentar a varias situaciones bastante comunes en todos las organizaciones.

Una de estas situaciones comunes es sin duda la siguiente:

  • Tenemos dos aplicaciones: por ejemplo la aplicación que gestiona los clientes y la que gestiona las cuentas corrientes.
  • Cada una de estas aplicaciones pertenece a un departamento o área concreto del banco.
  • Siguiendo una filosofía SOA ambos han construido servicios de negocio reutilizables por el resto de la organización.
  • Tarde o temprano, más bien temprano, aparece la necesidad de un servicio de más alto nivel que combine la funcionalidad de cada uno. Por ejemplo: consultar las cuentas de un cliente.

Estrictamente hablando, esta funcionalidad no pertenece a ninguna de la apliciones ya que queremos que a partir de un nombre y apellidos se recupere del servicio de Clientes el DNI o código interno de cliente y con éste invocar al servicio de cuentas para que consulte todas las cuentas relacionadas con este identificador de cliente.

Ahí va la pregunta del millón:

¿quién tiene que hacer este servicio compuesto que combina ambas funcionalidades?


Obviamente este servicio es útil para la organización y con toda probabilidad será reutilizado por otras aplicaciones. ¿Debe hacerlo la aplicación de Clientes o la de Cuentas? Creo que la respuesta más razonable sería: ni uno ni otro.

Tiene que haber un rol diferente, que tenga una visión más general de las necesidades de la empresa. Un rol que podríamos llamar arquitecto de aplicaciones.

La persona o personas que desarrollen este rol en la empresa deben de tener en cuenta esta situación concreta pero también tener en consideración las necesidades presentes y adelantar las necesidades futuras generales para la empresa.

No hay que olvidar que los servicios SOA deben ser reutilizables. No sirve de nada construir un servicio que sólo valga para una situación concreta. Evidentemente esta generalización (lograr que los servicios valgan para el resto de la organización) no es trivial. Por eso se necesita este rol de Arquitecto de Aplicaciones (el nombre puede ser otro), alguien que no pertenezca a un área en concreto y que sea capaz de saltarse los límites de un área o departamento concreto.

Si SOA ha terminado con las aplicaciones departamentales, las aplicaciones “silos”, logrando que todos ofrezcan y consuman servicios de los demás: ¿podemos seguir con un modelo organizativo en el que sólo aplica el límite departamental? Por supuesto que no.

Comparte esta entrada:
Share

Anuncios