Proyecto de definición del método data warehouse 2.0
A veces, esto requiere crear primero algunas dependencias, como configurar la infraestructura inicial del almacén de datos. Sin embargo, inicialmente se debe evitar la infraestructura de almacenamiento de datos final. Comience con algo pequeño, pero hágalo escalable. Infraestructura con demandas crecientes.
A menudo, los arquitectos intentan crear una solución de almacenamiento de datos capa por capa: deciden sobre un conjunto inicial de sistemas fuente para entregar todos los informes requeridos o cubos OLAP (procesamiento analítico en línea). Luego, implementan toda el área de preparación para capturar todas las tablas de origen, incluido el ETL de las tablas de carga. Una vez que completaron el área de preparación, comenzaron a modelar el almacén de datos empresarial lo más fielmente posible porque sería demasiado costoso contactar a TI en el futuro. Una vez implementado el trabajo de carga de trabajo ETL, se crea un data mart para satisfacer en última instancia a los usuarios comerciales. Este enfoque suele llevar meses, si no años, e incluye varias etapas de depuración y corrección de errores. Sin embargo, los problemas surgen cuando los requisitos cambian ("con demasiada frecuencia", diría el arquitecto en este ejemplo) o cuando la empresa requiere funcionalidad adicional (en muchos casos, el arquitecto original abandonó la organización).
Dado el modelo y la arquitectura extensibles y los métodos ágiles del estándar Data Vault 2.0, los arquitectos de almacenes de datos ya no necesitan seguir este enfoque. El almacén de datos no se establece de forma horizontal, capa por capa, sino de forma vertical según características. El objetivo general de una iniciativa de almacenamiento de datos es el mismo, pero ahora se logra mediante la entrega incremental de funcionalidad. El objetivo del equipo de BI es ofrecer la funcionalidad requerida en versiones rápidas y frecuentes, como se describió anteriormente en este capítulo. Para hacer esto, el alcance de la función debe limitarse a una única función que esté lo más separada posible de otras funciones.
La forma recomendada de lograr este objetivo es utilizar el método de definición del alcance en la ingeniería de requisitos y la implementación de características individuales, como se muestra en la Figura 3.11.
En el ejemplo que se muestra en la figura la característica a implementar es un informe, pero podría ser cualquier otro artefacto requerido por el usuario. Por ejemplo, podría ser una nueva dimensión o atributo en un cubo OLAP, un único cubo OLAP nuevo (con la dimensión más pequeña) o un corpus para minería de texto. Una vez que la empresa ha definido el alcance y descrito el artefacto, comienza a identificar las fuentes (tablas en el sistema fuente) necesarias para crear este informe único. A continuación, diríjase al centro de información para evaluar dónde es apropiado entregar los informes requeridos (u otra funcionalidad). Una vez realizada esta identificación, los ingenieros pueden preparar los datos requeridos, crear y cargar entidades de bases de datos y crear mercados. Al seguir este proceso, todos los datos de la tabla de origen se cargan y modelan en Data Vault, en lugar de un conjunto parcial de atributos. Por lo tanto, solo se puede contactar con la tabla de origen una vez, no varias veces. Para evaluar la disponibilidad de los datos, debería ser posible rastrear qué datos se han cargado en el almacén de datos de la empresa. Los datos parcialmente cargados hacen que la evaluación sea más compleja, que es lo que queremos evitar. Además, cargar solo datos parciales de la tabla de origen da como resultado un satélite Data Vault más complejo.
Definir los artefactos (es decir, cambios de requisitos) que se desarrollarán en la iteración es un requisito previo importante para el éxito de la iteración. El alcance adecuado reduce el riesgo de que el equipo no pueda completar e implementar cambios dentro del plazo del sprint. No es posible realizar sprints cortos de dos semanas o incluso de una semana si no está seguro del alcance del cambio requerido. Además, gracias al modelo Data Vault 2.0, los equipos ahora pueden crear soluciones de forma incremental en todas las líneas de negocio, para que puedan seguir siendo flexibles dentro del alcance de su implementación.
Debemos tener en cuenta dos objeciones: la primera es implementar todas las tablas de una fuente para mantener bajo el costo de integrar el sistema fuente; en este caso, cargar la solución actual no requiere datos.
Cargar estos datos requiere capacidades ETL adicionales, lo que requiere una infraestructura inicial más grande. Además, es posible que la implementación de todas las tablas fuente de un sistema fuente no se complete en un solo sprint, y la mano de obra disponible para implementar las funciones que se entregarán a la empresa está limitada. Este esfuerzo a menudo supera la complejidad de evaluar los datos que ya existen en el almacén de datos (tenga en cuenta que las tablas son bastante sencillas). Otro tema es que también es una buena práctica integrar los datos en el Data Vault cuando las tablas fuente se materializan en el área de ensamblaje. De lo contrario, se requiere complejidad adicional para evaluar el estado actual del almacén de datos cuando los dos sistemas pueden no estar sincronizados. Si se sigue este enfoque, cargar todas las tablas de origen requiere un modelado y carga completos de las tablas de Data Vault correspondientes.
La segunda objeción es que resulta caro tocar el objetivo varias veces para llegar a una solución final. Esto puede ser cierto, pero el objetivo final es ofrecer funcionalidad útil y procesable a la empresa en un sprint porque reduce el riesgo de falla: la empresa no acepta la solución, por ejemplo, porque no cumple con los requisitos escritos, Mientras tanto, los requisitos cambian o la solución resulta incorrecta una vez que los usuarios empresariales realmente la utilizan.
Este método de transferencia vertical de información se implementa en sprints. Dependiendo de las capacidades organizativas, esto puede tardar de dos a tres semanas. Por lo tanto, modelar un Data Vault no debería llevar meses. En cambio, los modelos deberían crearse durante la fase de sprint. Si lleva más tiempo, es un buen indicador de que el sprint es demasiado grande. En este caso, la función debe eliminarse del sprint. El objetivo de este sprint es eliminar todo lo que no es necesario entregar como una sola característica. Asegúrese de que los usuarios empresariales comprendan que esta función aún no está disponible, pero lo estará en un sprint futuro. A menudo, los usuarios empresariales suponen que la función se eliminó por completo porque se planeó eliminarla del sprint. Sin embargo, esto es incorrecto porque la funcionalidad que falta se entregará en la próxima iteración o poco después. Los usuarios empresariales naturalmente adoptarán el programa una vez que vean el progreso del proyecto.
Antes de implementar una nueva característica en un sprint, debes definirla. Sin embargo, el proceso de recopilación de requisitos es muy similar al proceso de implementación. Normalmente, las empresas tienen una idea aproximada de la funcionalidad que desean implementar en su almacén de datos. Pero todavía tiene muchas preguntas que responder, como preguntas sobre fuentes de datos, reglas comerciales para agregar o transformar datos, tipos de datos, casos de uso, etc. Para responder a estas preguntas, se utiliza un conjunto de requisitos.
Para respaldar el enfoque ágil de recopilación de requisitos, los requisitos se recopilan a lo largo de un proceso. A diferencia de los almacenes de datos tradicionales, estos requisitos se recopilan al inicio del proyecto. El enfoque más eficaz en nuestro proyecto fue utilizar raw marts y enviar rápidamente los datos a las reuniones de requisitos para su revisión. Estos raw marts se utilizan para crear informes o cubos para un número limitado de usuarios comerciales que participan en reuniones de requisitos, pero no para distribución. Esto se debe a que el mercado original contiene datos sin procesar que pueden o no implementar completamente las reglas comerciales. Al mostrar estos informes a los usuarios y preguntarles "¿Qué hay de malo en este informe?", resulta que los usuarios comerciales pueden señalar fácilmente los problemas con los informes y, al hacerlo, proporcionar todas las reglas comerciales necesarias para implementar el informe final.
Los pasos de este método de toma de requisitos son los siguientes:
Hasta el momento se tiene controlado el tiempo de entrega. Es su responsabilidad ser lo suficientemente ágil para llegar tan lejos. El siguiente paso está impulsado por la parte comercial del proyecto:
Una vez que se reúnen los requisitos, al menos en parte, se impulsa el proyecto nuevamente al hacer cumplir las reglas comerciales y otros requisitos:
En estas reglas de negocio, después de ser implementadas por TI, la parte comercial del proyecto puede revisar y probar el resultado, y si no están satisfechos con el resultado final, solicitarán más cambios. Sin embargo, estas modificaciones se convierten en cambios de requisitos y se implementan en sprints posteriores. El proceso ágil de recopilación de requisitos descrito ayuda a los usuarios comerciales a expresar sus reglas comerciales. Para muchos de ellos, el enfoque tradicional en los documentos de requisitos es demasiado abstracto e impide la identificación necesaria para identificar problemas con los borradores de informes.
El enfoque recomendado es registrar estas reuniones de requisitos y crear un sitio wiki para todos en la organización. Las actas de la reunión, incluida una descripción de las reglas comerciales descubiertas, deben registrarse en el sitio web para garantizar la transparencia en el proceso de recopilación de requisitos.
El mecanismo Web2.0 permite a los participantes comentar e incluso modificar las reglas comerciales según su propio entendimiento. Este enfoque primero garantiza que los requisitos sean correctos. Si hay mucha discusión en el sitio, es posible que sea necesaria otra reunión de requisitos para aclarar cualquier problema pendiente antes de que pueda comenzar la implementación. Celebrar estas discusiones antes de la implementación real significa enormes beneficios para la organización y una mayor productividad, lo que es un factor que contribuye al éxito general del proyecto. Para poder asumir correctamente que las funciones del equipo se pueden completar en un sprint, lo cual es importante para definir el alcance, el equipo debe poder hacer estimaciones correctas del esfuerzo requerido para completar ciertas funciones. Este tema se discutirá en el próximo artículo.