sedimentación

Como prácticamente no existen grandes sistemas empresariales de I.T. totalmente nuevos, no nos queda otro remedio, si queremos implantar SOA, de partir de un sistema que no es SOA. Es decir, un sistema que se ha construido como las cordilleras montañosas, mediante la sedimentación de varias capas a lo largo de mucho tiempo, alguna que otra erupción repentina y algún que otro, como no, terremoto…

Pues bien, ¿como hacemos para pasar de un sistema a otro sin romper nada?

Hay que seguir, en mi opinión, tres ejes de acción:

  1. Eliminar las conexiones directas entre aplicaciones
    Muchos de los problemas y riesgos detectados se deben en gran medida a las conexiones directas (punto a punto) entre aplicaciones. Esto provoca un gran acoplamiento entre las mismas y dificulta su evolución y adaptación a las nuevas necesidades funcionales.
  2. Establecer un intermediario (bus) entre las conexiones de todas las aplicaciones
    Las conexiones punto a punto implican que es necesario implementar cada conexión cada vez. Cada una de estas conexiones normalmente necesitan adaptar el formato y protocolo de ambas partes involucradas en la misma (cliente y servidor). Esto provoca que sea necesario implementar cada vez más conectores ad-hoc para cada conexión.
    Ojo que esto no quiere decir necesariamente que necesitamos un ESB. Existen muchas alternativas a tener en cuenta dependiendo de la situación y necesidades presentes y futuras de la empresa, desde un framework de integración como Spring Integration o Apache Camel, a un ESB más sencillo y gratuito como MuleESB o un suite de Middleware comercial.
  3. Establecer el principio de propiedad de los datos.
    Los datos (de una tabla) son propiedad de una lógica de negocio y por extensión de una aplicación. Ninguna lógica de negocio que no sea propietaria de los datos puede acceder a ella directamente. Siempre tiene que hacerlo a través de la lógica de negocio que es propietaria.

Creo que son estos los tres puntos sobre los que hacer girar todo nuestro diseño de como será la arquitectura futura (modelo TO BE), teniendo en cuanta de que partimos de un modelo (AS IS) que seguramente no tendrá que ver nada con SOA, pero del quedemos hacer la transición dentro de unos plazos, de un presupuesto y sobre todo, sin romper nada y que el negocio siga levantando la persiana todos los días para atender a nuestros clientes.

¿y tú? ¿Por donde empezarías la transformación de un sistema existente a SOA?