Diseño de Notificaciones sobre las transiciones de estado

Las notificaciones acerca de los cambios de estado
deben ser realizadas como parte de un buen
 proceso de diseño de una buena solución

En los últimos post hemos estado conversando sobre aspectos vinculados al diseño de una solución de gestión de información dinámica. Hemos hecho algunos énfasis en la caracterización de los estados (valores críticos que definen donde los objetos de información se encuentran) y de las transiciones de estado: el salto que ocurre cuando en un objeto de información un estado cambia de un valor a otro. Hoy queremos referirnos al diseño de las notificaciones que debemos realizar para participarles a ciertos usuarios la necesidad de su atención a un cierto cambio ocurrido en la información que maneja un sistema.

Como hemos visto un estado es siempre, por definición, una propiedad de un objeto de información que es importante por alguna razón y por ello nos interesa no solamente conocer cuál es su valor, sino su historia de cambios. Probablemente quién hizo cado uno de los cambios previos y cuándo lo hizo. Estos cambios de valores sobre un metadato crítico lo llamamos transición de estado.

Cuando ocurre una transición de estado, por ejemplo, cuando un trámite es aprobado (¡o reprobado!), normalmente hay acciones que hay que realizar dentro de un sistema. Pero muy típicamente hay que avisarles a ciertos usuarios acerca del cambio sucedido, para que estén  en cuenta del mismo, o para que hagan algo.

El mecanismo universal que normalmente se usa para este tipo de avisos es el correo electrónico, si bien es común en algunos casos que los usuarios reciban en forma adicional un mensaje de texto vía teléfono celular.

Lo anterior tiene implicaciones para el trabajo de deben realizar los Arquitectos de Información en la fase de diseño de un sistema. Por supuesto, deben caracterizar los objetos de información con todos sus campos o metadatos. Entre ellos, deben identificar cuáles son estados (campos en los cuales interesan no sólo sus valores sino su historia).  Deben definir los valores posibles que pueden tomar estos campos (el lenguaje controlado) que se usará y las transiciones posibles, a que valores se puede ir desde cada valor previo del estado.

Además deben definir las comunidades (grupos de usuarios) que pueden cambiar estos valores y en ocasiones, que pueden asignar ciertos específicos valores, por ejemplo, aprobar, reprobar o delegar la aprobación.

Finalmente, los Arquitectos de información deben trabajar en las notificaciones: Los avisos de los cambios. Lo más típico es que cada estado tenga un conjunto de usuarios que lo escuchan y un conjunto de usuarios que pueden hacer los cambios. A ambos conjuntos hay que enviarles las notificaciones. Estas deben tener un encabezado, un conjunto de  destinatarios, un cuerpo y un pie. Estos valores deben ser especificados en el diseño de manera que los constructores sepan exactamente lo que deben hacer. El diseño de las notificaciones ante las transiciones de estado es, así pues, un aspecto más que debe completarse en la ejecución un buen procedimiento de diseño de una buena solución.