Los datos de negocio viven donde les da la gana

netzima

¿No sería estupendo que en las empresas estuviera estandarizada la tecnología de persistencia de datos?

Está claro que sería toda una ventaja y una gran ayuda para desarrollar el trabajo del día a día.

Además, gestionar simultáneamente datos de prueba que residen en distintas bases de datos es más complicado de lo que parece.

Y si sumamos que están soportadas por tecnologías distintas estamos hablando de una dificultad de varios órdenes de magnitud superior.

En este artículo te ayudaremos a resolver estos desafíos mediante prácticas al alcance de cualquier técnico.

¡Empezamos!

¿Cómo es la arquitectura de datos de negocio?

La arquitectura de datos de negocio es un modelo continuo que exige recorrerse sin interrupciones.

Idealmente, la información no está duplicada, ni representada varias veces ni siquiera de forma inconsistente.

Pero, la realidad es que la arquitectura de datos de negocio se materializa en modelos físicos de datos que adolecen de estas virtudes ideales.

Esto se debe a que las distintas aplicaciones que soportan los procesos de negocio de las organizaciones imponen condiciones que alejan práctica y teoría.

Normalmente, las aplicaciones – desde luego los productos estándar - exigen su propia base de datos y una manera propia de representar información común y, por tanto, la duplicidad de la información.

También hay que decir que esto va por barrios, es decir, depende de cada software.

Sistemas monolíticos, arquitecturas centralizadas.

Hay organizaciones con una arquitectura de sistemas con una base de datos esencialmente centralizada y las aplicaciones trabajan sobre ella.

Es el caso de muchas entidades financieras, que construyeron sus aplicaciones bajo el paradigma del sistema monolítico.

Aun así, estas tampoco se libran de las duplicidades.

¿Cuántas integraciones entre entidades bancarias se han producido en los últimos años?

Muchas, ¿verdad?

Esto ha acabado derivando en duplicidades, aunque sean temporales.

Sistemas especializados, arquitecturas descentralizadas.

Otras organizaciones, por el contrario, han seguido el camino de elegir para cada proceso de negocio una aplicación especialista.

Es decir, una aplicación con su propia base de datos e integrada con el resto de aplicaciones.

En este escenario, la duplicidad de datos es una premisa de diseño.

3 capacidades que debemos exigir a nuestra estrategia de gestión de datos de prueba.

Por todo lo visto anteriormente llegamos a la conclusión de que gestionar datos de prueba significa ser capaz de lidiar con diferentes representaciones de la misma información y en distintas tecnologías.

Para desplegar con éxito una estrategia de gestión de datos de prueba en estos entornos complejos es necesario asegurar la capacidad de:

1. Representar de la arquitectura de datos de forma independiente de la tecnología que la soporte.

De esta forma, el responsable del diseño de la estrategia TDM puede trabajar en un entorno aislado de las complejidades técnicas abstrayéndose de la tecnología que existe detrás del modelo y entidades con sobre las que define la estructura de segmentación.

2. Definir y utilizar relaciones entre los datos que crucen las fronteras de las aplicaciones y las tecnologías.

Esto es crucial a la hora de gestionar los datos de forma transversal a varias aplicaciones.

Las aplicaciones no se prueban por sí mismas, habitualmente requieren de consistencia con los sistemas con los que se integran.

Dado que los modelos de datos de las propias aplicaciones no van a proporcionar esa capacidad de relacionarse unas con otras debe ser una capa funcional de orden superior.

3. Conectar con bases de datos de distintas tecnologías.

En último término, gestionar datos de prueba requiere interaccionar con las bases de datos que soportan las aplicaciones. En ocasiones, incluso mover desde un tipo de fuente de datos a otra de distinta tecnología. ¿Qué tecnologías encontramos habitualmente?

Para realizar un buen trabajo es imprescindible relacionar aplicaciones soportadas por distintas bases de datos. Incluso una misma aplicación puede delegar en diferentes tecnologías de almacenamiento en función del propósito.

La tecnología de icaria es capaz de manejar distintas bases de datos a través de las interfaces estándar que estas proporcionan. Como ejemplo, las conexiones a Oracle, DB2, PostgreSQL, SQL Server, etc.

También es necesario implementar conectores dedicados que permitan un correcto funcionamiento de las distintas funcionalidades de una herramienta TDM con estas fuentes de datos.

De este modo, la tecnología de icaria dispone de conectores específicos para HIVE, HDFS, ficheros planos, separados por comas, etc. Algunos incluso requieren de sistemas mixtos como puede ser el tratamiento de datos en SAP o Salesforce.

Todo ello se realiza con el objetivo de conseguir realizar:

  • La segmentación de datos.
  • La disociación.
  • Las búsquedas.
  • Los casos de prueba.
  • Y otras actividades que lo requieran.

Conclusión.

En definitiva, es una realidad habitual que exista duplicidad de datos en entornos complejos, independientemente del tipo de negocio con el que trabajemos.

Para que responsables y profesionales de QA ejecuten con éxito su estrategia de gestión de datos es fundamental que garanticen la capacidad de representar la arquitectura sin depender de la tecnología que la soporte.

La tecnología de icaria supone una ventaja a nivel de ahorro de tiempo y costes de implementación debido a que todo está en un mismo soporte y, además, permite coherencia de datos, debido a que trata simultáneamente diferentes fuentes de datos y los manipula siguiendo las necesidades y características del entorno.

Estas buenas prácticas las aplica el equipo de icaria en proyectos para gestionar los datos de prueba de software a través de la tecnología de icaria TDM.

¿Te gustaría saber más de nuestra tecnología? Contacta ahora con icaria Technology y descubre cómo podemos ayudarte con tu proyecto.

También te puede interesar:

Relaciones entre los datos: ¿cómo las identifico?

¿Por qué la protección de datos en los entornos de prueba no debería ser una preocupación?

¿Cómo se pueden mejorar las pruebas en el desarrollo de software?

Compartir:

Share on facebook
Share on twitter
Share on pinterest
Share on linkedin