BPM con referencias

Una de las premisas fundamentales para que un BPMS de buen resultado es que los procesos BPM deben de mandar hacer cosas, pero no hacer cosas ellos mismos. O dicho más formalmente: En automatización de un proceso BPM debe de centrarse el foco en secuenciar las tareas que se han de realizar, no en realizarlas. Entre las cosas que se debe de evitar, está la de mantener entidades de las que no se es responsable.

Así pues, y atendiendo al principio de responsabilidad del dato, la base de datos del BPMS deberá de mantener únicamente datos propios del proceso, e irá a buscar las entidades externas cuando las necesite.

Esto es especialmente importante en BPM, ya que entidades como cliente, cuenta, contrato, etc. que son subsceptibles de ser modificados por varios procesos o por eventos de forma concurrente, y un proceso BPM puede durar el tiempo suficiente como para que bloquear esos recursos no sea posible; debend e ser modificables de forma asíncrona.

Adicionalmente si los datos son responsabilidad de terceros deberemos de asumir que una vez adquiridos los datos, al poco, dichos datos dejan de ser validos.  Tras la primera tarea de usuario o automática que lleve más de unos segundos debemos descartarlos, y volver a pedirlos. No es necesario que alguien cambie los datos, la mera posibilidad de que alguien pueda haberlo hecho invalida los datos. Así pues no tiene sentido guardarlos.

¿Qué pasa con los datos que son responsabilidad del BPMS?

La responsabilidad sobre el dato; de EAI a API

Una de las diferencias mas destacables entre EAI y SOA es que mientras EAI pretendía mantener sincronizada la información entre sistemas mediante la copia de dichos datos en los diferentes sistemas a medida que se producían cambios. SOA por su parte proporciona servicios para acceder a los datos de forma remota, evitando la necesidad de duplicar datos.

Hay que reconocer que todo lo que se puede hacer en SOA, se puede hacer con EAI. Del mismo modo que todo lo que se puede hacer en API se puede hacer con SOA. Son solo cambios de enfoque. Pero si pensamos que en realidad todo se puede hacer con rutinas de ensamblador, nos damos cuenta que los cambios de enfoque no son cambios desdeñables.

En SOA las entidades (datos) deben de existir en un solo sistema. Este sistema ofrece servicios a terceros para acceder a estas o modificar estas entidades. Se dice que el sistema que ofrece ese servicio es el responsable del dato. Un único sistema que controla y secuencia las operaciones garantizando seguridad y calidad del dato, y que mantiene y proporciona la copia «buena» del dato a quien la necesite.

Cualquier otro servicio puede replicar para sí, datos de los que no es responsable con el fin de agilizar el procesamiento (por ejemplo para poder crear vistas sql conjuntas). Pero ha de ser consciente de que su copia no es la copia valida, y que por tanto debe de tender a pedir en cada momento una copia actualizada del dato a su sistema responsable. Esta tendencia nos lleva a mantener referencias de los datos de terceros, en vez de copias.

#api, #eai, #eda, #soa