viernes, 30 de agosto de 2013

Formulación de “Reglas de negocio”

La formulación de reglas de negocios no nos dice
cómo construir una solución, pero nos aclara en los procesos,
(qué es lo que hacemos) y por ello siempre son parte
(implícita o explícita) de la solución
Una de las técnicas modernas usadas por los Arquitectos de Información para construir modelos de información es la identificación de las reglas de negocio, aquellas características esenciales  que definen el manejo que se hace de la información en una institución dada. Esto es muy interesante porque las reglas de negocio son propiedades de los sistemas de información que son independientes de su implementación tecnológica e, idealmente, si están bien formuladas, son independientes de los valores puntuales de muchas propiedades con las que se gestiona la información en una institución. Atendiendo algunas preguntas que nos llegan a nuestro buzón, haremos un paréntesis para dedicar este post y quizá algún otro para describir un poco lo que estas reglas son y cuán útiles pueden resultar a gerentes de información, profesionales de la informática y arquitectos.

En primer lugar hay que aclarar es el uso de la palabra negocio. La palabra negocio en español tiene varios significados. Aquí la usamos en el primero de estos significados reseñado por el diccionario de la Real Academia de la Lengua Española. “Ocupación, quehacer o trabajo”. Por tanto una regla de negocio es, simplemente, un comportamiento general que se da en la información que manejamos en aquello de lo que nos ocupamos (No debe confundirse negocio con ocupaciones lucrativas, una acepción válida de la palabra en español, pero fuera de lugar en este contexto en la Arquitectura de Información).

Identificar una regla de negocio es descubrir una propiedad o comportamiento que tiene la gestión de información que realizamos.

Una regla de negocio, puede determinar cuándo una transacción puede o no realizarse. Por ejemplo: para que un trámite sea válido en una institución, es común que deben estar presentes varios documentos de soporte que se consideran obligatorios.

Una regla de negocio puede ser un refinamiento particular de una regla de negocio previa, más general. Por ejemplo, podemos decir que un documento está vigente cuando su fecha de caducidad es posterior a la fecha actual. Combinando los dos ejemplos anteriores: para realizar un cierto tipo de trámite requerimos que el otorgante (un rol) revise que estén presentes todos los documentos de una cierta lista de documentos obligatorios para ese tipo de trámites, pero validando además, que estos documentos estén vigentes.

Notemos que las reglas de negocio no son propiedades de una única formulación. Es decir, en una situación dada, puede haber varias declaraciones válidas para una misma regla de negocio. También puede haber reglas de negocio enunciadas en forma más simple o más compleja, más general o más particular. Debido a ello, la recomendación es que Arquitectos de información y gerentes formulen sus reglas en forma relativamente simple, limpia, es decir, lo más entendible posible por las otras personas.

Como solemos muchas veces recomendar, es bueno que nuestros lectores caigan en cuenta que las reglas de negocio son formulaciones que simplemente ayudan a entender mejor lo que hacemos con la información y son por tanto parte de la solución, independientemente de herramientas y tecnologías con que implementemos a ésta. Invertir tiempo en definir reglas de negocios no nos dice cómo construir una solución, pero nos aclara a nosotros mismos el qué es lo que hacemos o queremos hacer.

viernes, 23 de agosto de 2013

Los cronogramas después del modelado

Todo proyecto de gestión de información debe plantearse un cronograma
guía. Pero los ajustes después del diseño detallado son obligatorios ya que
las estimaciones hechas antes del análisis de los detalles del problema y la
solución son poco confiables.
Muchas personas creen que el ideal de un gerente es el cumplimiento estricto de todos los cronogramas que se plantean al inicio de un proyecto. La realidad no es así en el desarrollo de sistemas de información. Como veremos en el post de hoy, un gerente que cumpliera de esa forma los cronogramas de inicio de proyecto no sería un buen gerente, sino uno muy malo. De hecho es muy probable que, independientemente de las relaciones de autoridad que mantenga, inherentes a su cargo, alguien así sea muy poco acreditado en el juicio interno de quienes se relacionen con él: colegas, trabajadores, proveedores, clientes. Independientemente de las opiniones que se expresen en forma abierta, seguramente entre los relacionados comentarán acerca de la inflexibilidad, testarudez y dudosos conocimientos de integración y del ciclo de vida de los proyectos del amigo en cuestión. Eso es porque efectivamente, aunque muchos no los puedan verbalizar adecuadamente, hay  elementos dinámicos, propios del ciclo de vida del desarrollo de sistemas donde de veras hay evolución y creación de conocimientos y éstos necesariamente impactan los cronogramas iniciales.

Cómo hemos visto en otras oportunidades (ver por ejemplo El ciclo de vida... y Desarrollo, Implementación y Producción...), toda  nueva solución recorre un camino signado por distintas  fases: definición, diseño, desarrollo, implantación y producción.

En la fase de Definición se conceptualiza inicialmente el problema de información, en la fase de Diseño se trabaja con los detalles del modelo de información que se requiere, en la fase de Desarrollo se realiza la construcción del prototipo inicial de la solución, siguiendo las pautas que marca la fase de diseño y en la de Implementación se realiza la transición de la solución desde el equipo de desarrollo hacia el equipo que se encargará de él en la fase de Producción.

Si el problema no es trivial, si no se trata de un proyecto para seguir haciendo más de lo mismo y por tanto dejando todo sin mayores cambios, lo natural es que en el proceso iterativo de la fase de diseño o modelado se obtenga una mayor comprensión del problema y la solución ya que sólo después de todas sus actividades se logra una definición completa del alcance de un proyecto no elemental. Desde que es concebido hasta que se coloca en producción cada detalle de la solución debe ser sometida a pruebas de concepto de Arquitectura de Información para asegurar la calidad en su definición y/o implementación y este tipo de ajustes son naturales y recomendables, ya que mejoran el conocimiento incluido y la eficiencia del modelo de información a implementar.

Lo anterior significa que cualquier cronograma que se hubiese hecho al inicio del proyecto, antes del diseño detallado, es un cronograma realizado en un momento en el que el tamaño de la solución no podía estar bien definido precisamente por el desconocimiento de todos los elementos que nacen del análisis detallado de la información y la especificación del modelo de gestión. Las ideas iniciales son siempre demasiado bastas como para hacer estimaciones serias. Así como es poco confiable un médico que hace sus estimaciones definitivas antes de la biopsia necesaria para caracterizar un aparente tumor, así es poco confiable el profesional de la información que estima los recursos en forma definitiva y que pretende no hacer cambios en sus ideas después de caracterizar los detalles del problema y la solución.

Siempre que se trabaja con seriedad, los detalles de un buen análisis nos sugerirán una solución más larga o más corta, resuelta mejor con un procedimiento o con otro y por eso los cronogramas de un proyecto bien realizado deben ajustarse después del diseño detallado. No es impecabilidad sino inflexibilidad y  tozudez el ligar el éxito al cumplimiento de lo que se creía cuando no se tenían los detalles. Sería como el médico que se empeña en trabajar con la idea presumida inicialmente de un mal benigno después que se encontró, en el análisis, que el aparente tumor de su  paciente era un linfoma.

Si el proyecto no es pequeño y trivial, si es de mediano tamaño y no se trata de un proyecto que deja todos los procesos más o menos iguales, sino de una auténtica mejora, la sapiencia de la experiencia profesional comienza a brillar en el modelado, ya el que sabe sólo afirma categóricamente después que conoce.

viernes, 16 de agosto de 2013

¿A quién le notificamos los cambios?


En un sistema moderno los usuarios son participados en forma
permanente acerca de cada cambio que ocurre en los asuntos que
les conciernen. Pero hay detalles sofisticados en la definición
de estos procesos
No cabe duda que los sistemas de información modernos son más sofisticados que los que hacíamos en otras generaciones.  Es natural. Ahora podemos hacer más y lo hacemos. Los conocimientos y las tecnologías son más evolucionados.  Esa sofisticación se traduce para el usuario de aplicaciones modernas en que ahora, al menos en general,  hacer las cosas debe resultar más sencillo que antes. Pero  la sofisticación también incluye la complejidad. Es un hecho que ahora, en el rol de usuarios finales, podemos hacer cosas que antes no las considerábamos porque eran complicadas. Si cambiamos ahora el punto de vista a las perspectivas de los que construyen las aplicaciones, la sofisticación significa que hoy hay más cosas para especificar. Debemos hacernos preguntas sobre temas de los que antes quizá ni siquiera hablábamos. Es claro que alguna gente tiene ahora que preguntarse cuál es la mejor manera de construir y mantener un robot en la superficie de marte y que antes, cuando esto no existía como posibilidad,  la pregunta no se hacía. Con esta introducción hoy queremos profundizar a partir de una pregunta simple: ¿A quién le notificamos los cambios de estado que ocurren en un sistema?

Lo primero en que debemos hacernos conscientes es que los sistemas de información modernos notifican en forma sofisticada. Una premisa elemental es que todos los usuarios tienen, al menos, una dirección de correo electrónico y que, a través de ella, debe ser participado de los cambios que ocurren en la información de los sistemas y que tienen que ver con ellos.

Las experiencia de compra a través de la red, por ejemplo, nos muestra que al menos los cambios básicos, que el sistema reconoce que hicimos una orden, que nuestra orden fue despachada y que lo que ordenamos se considera entregado se nos informa por defecto en un sistema bien comportado. A partir de allí podemos enterarnos de estados intermedios de nuestra orden, por ejemplo, que lo que ordenamos está en tránsito entre un punto A y un punto B.  Así funciona un sistema moderno.

Notemos entonces de nuevo algunos aspectos de Arquitectura de información de los que hemos hablado: la información está constituida por objetos de información (ver Estructuras de información) y la dinámica de la información (ver Dinámicas de información) se traduce en que estos objetos cambian de estados (ver Transiciones de estado). De lo que se trata entonces es que un sistema moderno, sofisticado, debe informar acerca de las transiciones de estado a los usuarios involucrados (ver Diseño de notificaciones...). Si ahora tomamos la perspectiva del que diseña o del que construye una aplicación moderna debemos hacernos la pregunta de ¿A quiénes notificamos?

La respuesta también es sofisticada y tiene sus aristas. Cada estado definido dentro de un objeto de información de un sistema es un punto de llegada y un punto de partida. Los cambios son transiciones. Esas transiciones tienen que estar asociadas a comunidades de usuarios y lo normal (y el punto de partida por defecto) es informar en la ejecución de cada transición a todas las comunidades de usuarios asociadas a ella. Pero hay dinámicas de construcción de procesos dentro de estas dinámicas de producción (¡que sofisticación!): cuando estamos definiendo los mensajes a quienes debemos notificar es a los usuarios que participan en esta tarea, cuando creemos que los mensajes están listos debemos notificar a los validadores de los procesos, en principio, personas diferentes. Y cuando ya el proceso está definido, los mensajes deben llegar a las personas miembros de las comunidades involucradas en la transición misma (y no a los constructores y validadores de procesos).

La observación interesante es que todo esto es Arquitectura de información. Algo que no es software ni ingeniería sino diseño de procesos de información, de sistemas de información sofisticados, de esos que ahora podemos hacer y que hacemos y que socialmente marcan nuestra cotidianeidad de forma diferente. Los gerentes de información deben conocer la necesidad de este trabajo de Arquitectura de información en la fase de diseño de cualquier sistema moderno, independientemente de las herramientas de gestión de conocimiento, de información, de documentos o de software con la que vayan luego a construir sus sistemas.

viernes, 9 de agosto de 2013

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.


viernes, 2 de agosto de 2013

Los datos para probar

Los Arquitectos que trabajan cerca de los usuarios,
en sus ambientes reales, deben determinar los
datos de prueba de una solución durante
 la fase de diseño de la misma
Muchas veces, se tiene la idea de que las fases de desarrollo de una solución ocurren en cascada. Primero se concibe la idea, luego se diseña, luego se desarrolla, luego se prueba, luego se coloca en producción, luego se usa. Realmente la cosa no es así de fácil, sobre todo cuando hay el empeño en hacerlo bien y cuando la calidad del trabajo cuenta. Con esto en mente queremos hablar hoy de las pruebas, y más específicamente, de un detalle que a un gerente de servicios de información se le podría pasar inadvertido en algunos puntos del desarrollo de una buena solución de gestión en su sitio Web: los datos de prueba.

El desarrollo de soluciones de manejo de información que se hace hoy en día se caracteriza por su dinamismo. Siempre queremos que tengan usuarios rápido, pero es claro que para que nos vaya bien debemos probar su funcionamiento. Las preguntas son entonces ¿cuándo? y ¿con qué datos?.

Apenas se comienza a modelar o diseñar una solución hay que plantearse el tema de las pruebas. Dejarlo para luego puede implicar que nos planteamos el problema un poco tarde, obteniendo por ello dificultades e ineficiencias, que trabajando más proactivamente podríamos evitar.

En el ciclo de vida de una solución (ver) hay distintos tipos de pruebas. Las que realizamos como verificación de lo que estamos haciendo y las que realizamos como validación de lo que se ha hecho, trabajando junto con nuestros pretendidos usuarios. Las que prueban parcialmente aspectos modulares (pruebas unitarias) y las que prueban múltiples aspectos trabajando en forma integrada (pruebas de integración).

Un aspecto básico que debemos tener en cuenta es el momento correcto para la  génesis de las pruebas. Así pues debemos plantearnos la pregunta de cuándo, dónde y cómo deben generarse los datos de pruebas. Quizá pueda parecer sorprendente o exagerado, pero cuando se hacen bien las cosas los datos de prueba deben ser realizados cuando se está en la fase de diseño o modelado de la solución. ¿Por qué? Porque las personas que están realizando en ese momento el trabajo están en contacto directo con el problema, con los usuarios, con las condiciones de uso y saben qué es lo que se necesita y se espera que se haga como entrada y qué es lo que, en ese caso, debe obtenerse como salida.

Los constructores de la solución, arquitectos, informáticos o programadores deben realizar pruebas para asegurar que su creación está trabajando correctamente, pero para que sus pruebas sean pertinentes, realmente adecuadas, ellos deben usar data de prueba que las personas que levantaron la información, trabajando de cerca con el usuario, manejan. Los constructores conocen algunas restricciones, limitaciones y características de sus herramientas, procesos y métodos y aportan ello cuando hacen sus pruebas. Los datos de prueba introducidos por ellos pueden tener sentido, pero al mismo tiempo, ellos pueden no tener la misma consciencia sobre los contenidos de información específicos que tienen los arquitectos que trabajaron con los usuarios en el dominio de la aplicación.

Por ejemplo, algo tan simple como ¿cuán grande debe ser el tamaño de la caja que recibe un campo llamado asunto? es algo que en la construcción puede resolverse según la información que se tenga de los datos de prueba. Un campo Asunto, para un informático puede ser, razonablemente, de una línea, como las que siempre usa cuando escribe sus correos. Pero en una aplicación dada, por ejemplo, el Asunto en una correspondencia, un campo asunto debe ser algo bien descriptivo y debe por ello tener más de una línea. Este conocimiento lo tiene la persona que conceptualizó el sistema, al lado del usuario y es el a quien le corresponde definir los datos de prueba. Los constructores están obligados entonces a usar esa data y a incluirlas en su gestión de pruebas automatizadas.