Unos servicios reutilizables en la empresa deben implicar, como no, que usemos un lenguaje común en toda ella, que llamemos de la misma manera a la misma entidad de negocio, a sus atributos, etc. etc.

Debemos tener una capa de abstracción que defina un lenguaje común para la compañía.

En empresas muy grandes, con grandes departamentos dentro de ella, o también  aquellas que provienen de adquisiciones y fusiones con la heterogeneidad que ello implica, es posible que no se hable el mismo idioma de negocio en toda ella. Hasta puede ocurrir que se usen los mismos conceptos pero con significados ligeramente diferentes, lo suficiente como para dificultar la comunicación.

Si creamos un servicio con una funcionalidad de negocio que ponemos a disposición de otros departamentos, obviamente tendrá que tratar conceptos del mismo negocio. En cada sector hablaremos de clientes, cuentas, préstamos, pólizas, productos, viajes, etc. cada uno de ellos con sus atributos y su comportamiento.

Pero para que esto sea posible, es necesario definir un lenguaje común. Que un cliente sea un cliente de la misma manera en toda la empresa. Que tenga nombre y apellidos, por supuesto, pero también que tenga un tratamiento igual para toda ella (oro, plata, bronce o estándar o premium como queremos).

Ojo con la distinta nomenclatura de los datos en los distintos backends

En aquellos servicios que surgen de una iniciativa bottom-up, es decir que se forman con lógicas ya existentes en los backends se puede manifestar este problema con toda su crudeza. Ya que además de semántica propia de las entidades de negocio en cada uno de estos backend se añadirán también las particularidades de la nomenclatura de los datos.

¿qué pasaría si un servicio compuesto que recuperar el titular de un contrato de un backend y el producto contratado de otro backend? ¿Podríamos tener un servicio que devuelva el “TIT_CONTR” en un campo y en otro el” PC34822″ respectivamente? No si no queremos que el consumidor del servicio se vuelva esquizofrénico.

La alternativa es la torre de babel

Históricamente cada backend ha tenido una vida independiente y compartimentada respecto al resto de la empresa (un silo). Ahora, queremos reaprovechar estas lógicas para que toda la empresa se beneficie y que se pueda combinar con otras lógicas de otros backends con el fin de proporcionar a nuestros clientes servicios más complejos y con más alto valor añadido.

En una empresa es habitual tener personas dedicadas a consolidar el modelo de datos donde se guarda la información de la empresa (base de datos). Velan para que todos los campos tengan unas reglas de nomenclatura común, que no se dupliquen tablas y columns, que el modelo sea coherente, etc. etc. ¿por qué no hay algo así para los servicios web?.

Evidentemente esto no es fácil, ya que lo primero que hay que hacer es conseguir construir un glosario de términos comunes, primero los conceptos de negocio, después sus atributos.

La alternativa a esto, es la torre de babel y en definitiva que los servicios no sean realmente reutilizables.

Foto | Tico

Anuncios