20120623-204351.jpg

Hay una cosa que creo incompatible con una orientación a servicios,: el concepto de aplicación. Al menos el concepto que se ha manejado tradicionalmente.

Por supuesto, en un servidor de aplicaciones, dónde se ejecuta el software de la empresa, se necesita desplegar un artefacto, un fichero que “empaqueta” el ejecutable y que es el entiende el servidor. En el mundo java, este fichero se llama Enterprise Archive.

A este elemento fisíco, el desplegable al que me refiero, en tiempo de ejecución sí que se podría considerar una aplicacion. Más que nada porque nuestro software no puede “flotar” en el servidor.

Evidentemente el concepto de aplicación que manejamos nosotros no es tan físico, tan a bajo nivel. Tradicionalmente siempre hemos considerado las aplicaciones como conjuntos de la funcionalidad de negocio de una empresa.

En un banco, por ejemplo, es muy normal tener la aplicación de Personas, la de Prestamos, Riesgos, etc. Y esto tiene muchas causas, la primera es la tecnológica. En la era pre-SOA cada departamento tenía su propia aplicación independiente de las otras (aplicación silo).

La segunda administrativa o política. Si funcionalmente la empresa se organizaba en los departamentos de Personal, Prestamos y Riesgos ¿Qué aplicaciones iba a construir? No podrían ser de otra manera.

¿Tiene sentido circunscribir un servicio a una aplicación?

Con esta división organizativa de la empresa, ¿Que pasaría si pensamos en un servicio que da de alta a un cliente? Pues bien, no tendremos ningún problema, para esto está el departamento de Personas. Con su presupuesto y con su gente diseñarán y desarrollarán el servicio sin ningún problema porque solo dependen de ellos. Lo mismo pasaría para calcular el riesgo de una operación, para eso está el departamento de Riesgos.

Y ahora una cosa muy normal, la evolución lógica:Negocio necesita un servicio que evalúe el riesgo de una persona. Aquí vamos a tener un problema.

¿Quién es el propietario del servicio? ¿Quien tiene que hacerlo? ¿Con qué presupuesto?

El problema del servicio es que no encaja en la estructura organizativa de la empresa. Se necesita una comunicación y coordinación entre los departamentos a la que seguramente no están acostumbrados. No es una aplicación silo tradicional, entramos en un terreno desconocido.

Conclusión:

Si queremos que la adopción de SOA tenga éxito, debemos pensar que si los servicios deben colaborar con servicios de otros departamentos y áreas de la empresa, tendrán que hacerlo fuera del concepto de aplicación. Para ello, también los departamentos de la empresa deberán ser menos estanco y más proclives a la colaboración entre los mismos (de la misma manera que colaborarán sus servicios).

Comparte esta entrada:
Share

Licencia de Creative Commons
Pensando en SOA by Andrés Hevia is licensed under a Creative Commons Reconocimiento 3.0 Unported License

Anuncios