viernes, 26 de julio de 2013

Transiciones de estado


Cuando diseñan modelos, los Arquitectos de Información deben
determinar los estados posibles para los objetos de información y,
para cada uno de ellos,  las transiciones de estado posibles, y,
 para cada una de ellas, quiénes pueden registrar ese cambio
El trabajo de los Arquitectos de Información cuando diseñan una solución de gestión de Información es construir un modelo que siendo relativamente sencillo de entender, luzca cercano a la realidad y permita describirla y emularla. En algunos casos esto es relativamente fácil, en otros no lo es. Cuando se trata de un proceso dinámico, en el que hay flujos de trabajo, transacciones que cambian los estados en el que encuentran el sistema y ciertos objetos de información, uno de los aspectos claves es determinar cuáles son los estados que caracterizan a la información, qué determina dónde se encuentra un cierto objeto de información (una actividad, un trámite) y algo que hemos estado explicando en nuestros últimos post, las transiciones de estado. los pasos que trasmutan la información de un estado a otro. Es un tema interesante.

Los estados (Ver Estados de la información) son valores críticos que expresan el punto donde un cierto objeto de información está. Sirven para clasificar la información, pero por sobre todo, la caracterizan en su dinámica. "Pendiente de revisión", "Enviada a presidencia", "En proceso de análisis", "Otorgado", "Evaluando recaudos", "Aprobado preliminarmente",  "Esperando para ser impreso", pueden ser estados en los que se encuentran trámites en un momento dado. Ellos marcan las próximas actividades pendientes. En una institución ellos enrumban el flujo del trabajo y es importante su cruce con el tiempo, saber desde cuando el trámite está en ese estado.

Las transiciones de estado son la parte dinámica del asunto (Ver Dinámicas de la información). Lo que ocurre cuando un estado cambia. Son relevantes incluso desde el momento previo al ellas: la determinación de los próximos pasos posibles, qué es lo que puede ocurrir a un trámite que se encuentra en un cierto punto. Por ejemplo, llega el día de la exposición de una tesis ante un jurado. Esta tendrá como estados posibles: "Aprobada", "Aprobada con mención publicación", "Reprobada", "Prorrogada".  Lo que suceda marcará la transición desde el estado "En revisión por el jurado" a los valores mencionados arriba.

Así pues, en un sistema el arquitecto identifica los distintos tipos de estado posibles, los valores aceptables para ese estado y los valores posibles a partir de cada uno de ellos. Por ejemplo, siguiendo el caso de la tesis de grado, desde el estado "En desarrollo", se puede pasar a "En revisión por el jurado", pero no a "Aprobada" o "Reprobada".

Cada estado tiene otros que lo pueden suceder. Son las transiciones posibles. Es trabajo del Arquitecto de información hacerlas explícitas cuando construye el modelo de gestión.

Además de definir cada transición posible él debe determinar los roles que pueden generar esa transición. Cuál es la comunidad, el equipo, el grupo de personas que pueden cambiar el estado, vale decir, realizar la transacción. Hay varias posibilidades típicas. Trámites que pueden realizar varias personas o trámites que realiza sólo una. Si son varias personas estas pueden requerirse en forma conjunta para un siguiente estado o en forma indistinta. Puede que una puede hacer una transición directa a un estado que está dos escalones por delante y que otra sólo pueda avanzar el trámite a un punto donde alguien mas debe aprobar o realizar el avance al segundo escalón.

La Arquitectura de información puede no ser simple en si misma y el esfuerzo del arquitecto es lograr no sólo que su modelo trabaje, sino que se entienda. Al final es igual que en el ajedrez, no hay una única manera correcta de hacer las cosas y hay estilos en el hacer y huellas personales que se dejan.

viernes, 19 de julio de 2013

Dinámicas de la información

La información es dínámica y se caracteriza por estados que
se suceden iniciados por ciertos eventos sencillos.
Parte del dieño de una solución de gestión es especificar los
estados de la información y las transiciones de estado posibles
La información es dinámica. Cambia en el tiempo, y ciertos cambios ocasionan nuevos cambios en una cadena de eventos que se suceden en distintos ritmos y frecuencias. Cuando los gerentes de información no se preparan para esto tienden a pensar la información que gestionan como algo estático y eso les lleva a errores. De igual manera los que desarrollan sistemas de información en ocasiones comenten errores porque no modelan adecuadamente los procesos de cambio que ocurren en la información y sus consecuencias. En este post tratamos de explicar algunos aspectos de lo que significa entender y diseñar modelos de información que contemplan las dinámicas de información.

Cuando se quieren modelar dinámicas de información la primera cosa es asegurarse que se entiende bien la estática de la información. Esto nos lleva a recordar algunos conceptos de los que hemos hablado en otras oportunidades: estructura de información, objetos de información, campos de información (En este blog hay varios post marcados con la etiqueta Estructuras de información)

Una estructura de información es un modelo que se crea estableciendo un diseño de objetos de información y sus asociaciones o relaciones. Los objetos de información representan en los sistemas lo que afuera ocurre y se describen con campos que pueden ser identificadores, clasificadores y campos descriptivos (Ver Diseño de una solución y la Estructura de información). La información así estructurada se encuentra en siempre caracterizada por estados (ver Estados de la información) de modo que podemos decir cosas como "este expediente está en este estado", "este libro está prestado a fulano de tal", "esta correspondencia aún no está contestada", etc.

Ahora bien, si usamos los ejemplos anteriores para entender lo que significa modelar una dinámica de información podemos pensar en lo que sucede cuando el expediente pasa a otro estado, el libro es devuelto, la correspondencia es contestada, etc. Allí hay dos detalles en los cuales reparar: el primero es caer en cuenta que lo que ocurre es una "transición de estado", un concepto del que hablamos en nuestro post de la semana pasada. Los estados caracterizan lo que ocurre con la información en un cierto momento, pero lo que define una situación típicamente cambia y el cambio da pie a una transición de estado que se origina porque un evento simple sucede. En un sistema de información dinámico los Arquitectos de información deben definir en sus modelos las transiciones de estado, especificar quiénes pueden dispararlas o registrarlas y, muy importante, qué otros cambios deben ocurrir cuando un contenido de información puntual se mueve de un estado a otro. Estas especificaciones son aspectos importantes del diseño detallado de una solución dinámica.

Volviendo a los ejemplos: si un expediente cambia de estado, es probable que otras personas deban realizar ciertas actividades: revisar, validar, aprobar, autenticar, archivar, etc. Si un libro es devuelto seguramente se debe reubicar y hacer disponible, probablemente se debe enviar un mensaje de acuse de la devolución al que lo tenía prestado, quizá adicionalmente se debe realizar una operación de préstamo automática para alguien que había registrado previamente su interés y al que se le debe enviar un mensaje para avisarle que pasar por la biblioteca o, en algunos casos corporativos, se le debe enviar el libro a la oficina. Si una correspondencia es contestada deben hacerse actividades de seguimiento. Todas estas son acciones disparadas por transiciones de estado.

En síntesis, las dinámicas de la información se caracterizan por cambios de estado, hay actores que tienen que ver con las particularidades de esas transiciones de estado y hay que tomar en cuenta que normalmente se deben iniciar acciones con cada cambio de estado. Así, un modelo dinámico de información especifica los estados, las transiciones posibles, los actores involucrados y las acciones relacionadas. Una vez más debemos notar que hacer estas especficaciones es un trabajo de Arquitectura de información, independiente de las tecnologías, herramientas y software que se usen en la construcción de las soluciones.

viernes, 12 de julio de 2013

Estados de la información

En cualquier proceso de gestión, la información pasa por distintos "estados"
Uno de los conceptos que un Gerente y un Arquitecto de Información deben manejar es el de estado de la información. Los soluciones automatizadas de gestión de información se usan para registrar la información, consultarla, explorarla, presentarla de distintas maneras, proporcionar alertas para la toma de decisiones y controlar los flujos ordinarios de las operaciones o transacciones que sobre ella se realizan en una institución. Cada vez que sobre una cierta instancia de información se realiza un proceso, la información que se manejó queda en un determinado "estado". Esta condición define las próximas actividades posibles y  la capacidad de pasar a otros ciertos estados, si ocurren hechos específicos o se ejecutan ciertos procesos. En este post nos detendremos un poco a explorar este concepto de "estado", aquilatando su importancia en el diseño de soluciones de gestión.

Un estado puede entenderse como un valor que toma un cierto campo, variable o metadatos, en un determinado contexto. Como estos valores son definidos, los estados son, en cierta forma valores que toman clasificadores de tipo administrativo, predefinidos con vocabularios controlados (ver Campos clasificatorios de lenguaje controlado).

Pero un estado no es un mero clasificador, porque los estados los usamos para controlar el flujo de las operaciones y para hacer seguimiento de procesos y de allí que cada cambio de estado debe ser registrado en un sistema bien comportado. Esto hace posible seguir las líneas de tiempo de los cambios habidos en ciertos items de información, así como disponer de trazas que permiten hacer, eventualmente, revisiones de supervisión o auditorías.

Otro aspecto de los estados en que se diferencian de los simples clasificadores de vocabularios controlados es que, como los estados definen y expresan contextos, dado un estado, sólo ciertos otros son posibles. No se puede pasar de un estado a cualquier otro, por mucho que ese otro sea un valor posible para la propiedad en cuestión, en un sentido genérico. Los estados cambian según ciertas reglas. Por ejemplo, una correspondencia recibida puede estar en un estado llamado "Registrada y esperando por clasificación". De ese estado la correspondencia puede pasar a otro, llamado "Enviada al departamento A" o "Enviada al departamento B". En cada uno de estos departamentos otros estados serán posibles, pero puede ser que después de registrarla el operador no esté autorizado a colocarle al estado el valor "En cuenta", atributo que sólo puede ser realizado por los personas que tienen ciertos roles en la institución.

En la fase de diseño o modelado de una solución los Arquitectos de información deben definir con detalles cuáles variables deben ser manejadas como estados, porque interesa hacerles el seguimiento a sus transiciones y usarlas para controlar el flujo de la información. Para estas variables deben definirse no sólo los valores posibles, sino las transiciones de estado posibles. Es decir, cuáles son los próximos valores que puede tomar la propiedad dado el valor que tienen en un momento dado.

Esta lista de valores y definición de posibles transiciones es una parte muy importante del informe de diseño de la solución y es imprescindible como información para los que construyen, implementan o prueban una aplicación. Un aspecto interesante es que los estados y sus transiciones son completamente independientes de la tecnología que se use para construir la solución.

viernes, 5 de julio de 2013

Campos clasificatorios de lenguaje controlado

En una entrada de datos de "Clase" de animales es muy diferente el
comportamiento y la utilidad del campo clasificatorio si éste es de vocabulario
abierto o controlado. Si es de vocabulario controlado los valores deben
prefijarse en el sistema y el usuario sólo debe seleccionar una de las
opciones posibles
La semana pasada conversamos acerca de cómo se describe el detalle de la estructura de objetos de información en el diseño de una solución automatizada de gestión de información. La estructura de información es una pieza central que define el trabajo de los Arquitectos de Información en el diseño de la solución. Según vimos, se deben realizar varias tablas, una para cada objeto de información. Para cada una de ellas se especificaron cuáles deben ser los contenidos presentes que describen sin ambigüedades la estructura de información. A partir de allí queremos hoy referirnos a una información adicional que complementa la descripción de la estructura de información. Entre ellas las tablas de lenguaje controlado que se llenan para campos clasificatorios.

Tablas de lenguaje controlado
Es común que en todo sistema de información existan distintas categorías clasificatorias. De hecho, uno de los trabajos que debe realizar el Arquitecto de información es hacer explícito la presencia de estas categorías clasificatorias en cada tipo de objeto de información.

Según la naturaleza de sus contenidos, las categorías clasificatorias pueden ser de distinto tipo: temáticas, geográficas, estadísticas, administrativas, onomásticas, de control de flujos de trabajo, etc.

Adicionalmente según la manera como se llenan, las categorías o metadatos clasificatorios pueden ser de lenguaje controlado o folksonomías de lenguaje abierto que se desarrollan a medida que los usuarios las usan y que no son controladas por los sistemas a priori, como por ejemplo, las etiquetas que los usuarios colocan en los sitos de Internet donde guardan sus fotografías.

Cuando son fijas en el sistema, los valores de clasificación son preestablecidos y por tanto deben definirse claramente y precargarse en la aplicación. Al momento de la entrada de datos debe asegurarse que sólo se permitirá que los campos clasificatorios de este tipo puedan tomar uno de los valores preestablecidos. Por eso este tipo de campos clasificatorios se llaman de lenguaje controlado. Un ejemplo es una lista de países, de alternativas para indicar el sexo o de solicitudes de servicios ofrecidos por una organización. Los valores se ofrecen prefijados.

En la fase de diseño debe analizarse la consistencia de los valores definidos para los campos clasificatorios y el resultado de este análisis, en la forma de listas de valores válidos, debe especificarse en el informe que debe producirse para los desarrolladores que construirán la aplicación.

La especificación consistirá por tanto en un conjunto de tablas agrupadas por objeto de información las cuales tendrán los valores posibles para cada campo clasificatorio de lenguaje controlado que debe usarse en ese objeto de información, o una especificación referencial precisa para los valores posibles, como por ejemplo, un tesauro, o la codificación de idiomas usada en los estándares definidos por el consorcio de la W3.

Para cada uno de los objetos de información que se usará en una solución habrán tantas tablas como campos clasificatorios de lenguaje controlado haya y en esta sección del informe de diseño habrá tantos grupos como de tablas como objetos de información se hayan especificado en la sección de estructura de información que se describió la semana pasada.