Aprender a generalizar: Los valores constantes en las reglas de negocio

Los Arquitectos de Información aprenden a generalizar los
valores constantes en la formulación de reglas de negocio

La semana pasada estuvimos hablando de la formulación de reglas de negocio como una de las estrategias que usan los Arquitectos y gerentes de información para definir o caracterizar las propiedades de un  sistema que deben estar presentes en una solución automatizada, independientemente de las tecnologías que se usen en la construcción de la aplicación. Hicimos una introducción general a lo que las reglas de negocio son y vimos que éstas podían formularse de muchas maneras, si bien en general se recomendaba hacerlo lo más simple y entendible posible. Esta semana queremos complementar un poco el tema de la formulación de reglas de negocio ampliando como, en algunos casos, aunque suene menos simple, debemos buscar la manera de generalizar algunas de nuestras afirmaciones cuando usamos valores constantes.

Valores constantes son números, fechas, cantidades, roles, que resultan puntualmente específicos y que, en el trabajo que nos ocupamos, suenan como valores que permanecen inalterables en el tiempo.

Precisamente lo que ocurres es que, como lo sabe la gente de mucha experiencia, estos valores constantes en muchos casos dejan de serlo. Debido a ello es conveniente que encontremos maneras en que estos valores constantes puedan ser formulados en forma de abstracción simple, por ejemplo, hablando del número máximo, número mínimo, monto crítico, monto máximo de otorgamiento, monto mínimo de transacción, fecha de caducidad de la oferta, período de vigencia, etc. Este tipo de formulación normalmente aumenta la vida del enunciado que le damos a la regla de negocio. Y sólo requiere algunas definiciones adicionales.

Por ejemplo, si decimos "el precio de un grupo de ítems es de un 20 % por encima del costo", la regla queda atada al valor 20%. Si decimos "el precio está definido como el costo multiplicado por el porcentaje de venta establecida en la temporada", estamos en presencia de una regla que puede mantener su vigencia durante varias temporadas, con varios valores de porcentajes definidos para ellas. Por supuesto, nada es gratis en la vida, el cambio requiere que nos demos el trabajo adicional de definir los porcentajes en cuestión para cada temporada. Pero esto es sólo un valor en un sitio establecido, no una formulación de una regla de negocio.

Si nos referimos a “los recaudos para el crédito menor de cinco millones”, estamos en presencia de una formulación de una regla donde la categoría clasificatoria (el crédito menor de cinco millones) queda atada, innecesariamente, a un valor constante. En cambio, si alternativamente formulamos: “los recaudos para el crédito simple son estos”, estamos usando un tipo de enunciado (el crédito simple) que seguramente será más duradero, con la obligación, eso sí, de apuntar en algún lado de algún documento, que el crédito simple es un crédito inferior a los cinco millones.

Con la práctica los Arquitectos de información aprenden de esta forma a redactar reglas de negocio simples, entendibles y con el nivel de abstracción adecuado para que sean más duraderas. Lo interesante es que estas reglas de negocio forman así un lenguaje común que permite al jefe y a los colaboradores, a los diseñadores de modelos y a los constructores, conversar y entenderse en las distintas fases del desarrollo de una solución de gestión de información.

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.

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.

¿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.

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.