Arquitectura - La vista de información

La vista de información

Un componente de software se puede ver como una caja negra a la cual se ingresa información, éste internamente realiza un procesamiento y finalmente genera otra información procesada a partir de la información que le ingresó inicialmente.

El concepto es bastante simple pero a partir de la percepción podríamos afirmar que la complejidad del software aumenta exponencialmente cada vez que aumenta su alcance porque la cantidad de información que se debe contemplar, manejar y procesar es mucho mayor.

A lo anterior se le debe añadir que en la actualidad pocas veces hacemos “Stovepipe systems”, es decir sistemas que son islas y que están en capacidad de generar toda la información que necesitan para realizar su procesamiento. Evidentemente hoy debemos interactuar con toda una organización y esto se convierte en un reto no solo a nivel de gestión sino también a nivel de diseño e implementación del software.

Piensen en el siguiente escenario:

El cliente solicita la implementación de un componente de software, los analistas realizan la revisión de la funcionalidad e incluso tienen en cuenta los atributos de calidad, se hace un diseño conceptual de la necesidad, se estima y tiempo después se aprueba el inicio del proyecto. 

Lo primero que hace el equipo es hacer un plan y definir la arquitectura del sistema con el fin de garantizar que se contemplen las funcionalidades más representativas y los atributos de calidad. Finalmente se pasa a desarrollo.

El desarrollador empieza a implementar el sistema, diseña su base de datos implementa las funcionalidades y entrega al cliente. Cuando se hace la entrega el cliente dice: Nosotros ya teníamos un sistema x, y, z que ofrecía la información a, b, c que ustedes están almacenando en la base de datos, no podemos replicar información. ¡Plop!

Supongamos que en el mejor de los casos se tenga en cuenta la plataforma tecnológica del cliente y el desarrollador antes de hacer cada implementación solicita al cliente los contratos y la ubicación de cada uno de los servicios que requiere para hacer la implementación. Siendo optimistas el cliente gestiona al interior de la organización y entrega las definiciones al desarrollador o solicita la implementación de aquellas que no estén codificadas. Pero ¿qué pasa si esto no es así? ¡Impacto para el proyecto, un desarrollador sin nada que hacer porque depende de definiciones que no han llegado!.

La vista de información busca mitigar los siguientes riesgos:

• Que no tengamos en cuenta la plataforma tecnológica del cliente en la arquitectura y por ende en la implementación.

• Que no tengamos en cuenta la dependencia con otras áreas de negocio y/o otras personas y que por ende se impacte el proyecto por falta de disponibilidad o capacidad de estos.

¿Qué hacemos entonces para que esto no nos pase?

Lo primero que debemos hacer es identificar las necesidades de información al inicio del proyecto:

1. Leer la definición funcional del sistema (Requisitos, Casos de uso, Historias de usuarios, etc.) e identificar aquellos casos en los cuales se requiera cierta información o se deba entregar cierta información. No se pregunte en este punto si la información la debemos almacenar en un repositorio local a la aplicación o si será un sistema externo, lo importante es tener clara cuál es la información que requiere el sistema para poder realizar su procesamiento.
2. Revisar los prototipos de las interfaces graficas de usuario. Allí podrá identificar necesidades de información principalmente en las listas desplegables o en los campos de texto de autocompletar.

Una vez identificadas estas necesidades de información dedíquese a buscar al interior de la organización quien está en capacidad de ofrecerla, busque alternativas, acuda a otros proyectos e identifique si están haciendo algo similar que usted pueda usar y en tal caso realice acuerdos y diseñe un plan que contemple todo esto.  

Si nadie está en capacidad de ofrecerle la información que requiere entonces puede realizar el almacenamiento en un repositorio propio pero en éste punto usted estará tranquilo de que tuvo en cuenta las restricciones técnicas de sistemas legados de la organización y minimizará la probabilidad de impacto por este motivo.

El escenario con una vista de información clara es el siguiente:

El cliente solicita la implementación de un componente de software, los analistas realizan la revisión de la funcionalidad y a partir de ésta se identifican las necesidades de información, se hace un diseño conceptual de la necesidad, se estima, en la estimación se realizan asunciones sobre el origen de la información y se envía la estimación al cliente. Tiempo después el cliente retroalimenta aceptando o negando las asunciones y se aprueba el inicio del proyecto.

Lo primero que hace el equipo es revisar nuevamente las necesidades de información y en éste punto ir a las áreas de negocio involucradas de modo que puedan identificar puntos de integración a partir de los cuales se pueda obtener la información requerida, a partir de esto realizan el diseño de arquitectura del sistema esta vez contemplando las restricciones técnicas. Finalmente se hace un plan y se pasa a desarrollo. En el plan se incluyen dependencias con otros proyectos y/o áreas de negocio pero se tiene en cuenta su capacidad y disponibilidad por lo que la fecha final de entrega se mueve teniendo en cuenta los momentos en los que estos actores pueden entregar la información necesaria. 

El desarrollador empieza a implementar el sistema, diseña su base de datos solo para almacenar aquella información que no ofrezca otro sistema, implementa las funcionalidades y entrega al cliente. ¡Tuvimos problemas pero no tantos como al inicio y entregamos lo que esperaba el cliente!

Ventajas de construir la vista de información.

• La principal ventaja es que apoya la identificación de la plataforma tecnológica que posee el cliente porque en el proceso de identificación del origen de la información se debe buscar el apoyo de los involucrados en TI.

• Se tienen en cuenta las dependencias con otras áreas de negocio y/o proyectos en la elaboración del plan.