Planning a Proof of Concept

A proof of concept (POC) determines the feasibility of using XDM for the purpose of providing test data in your organization. As part of the proof of concept, XDM is installed in your environment, and you verify its ability to satisfy your requirements for a test data provisioning solution.

Scope of the proof of concept

To determine the scope of the XDM proof of concept, identify the XDM components that are of interest for your organization and create a list of features and test data provisioning scenarios that you would like to verify.

After XDM has been installed in your environment, the scenarios on this list are executed in databases that are typically not the production databases, but resemble the production databases in terms of object structure and amount of data.

At the end of the trial period, you can use the list to determine if the POC has been successful and justify the adoption of XDM.

The following section can be used as a guideline to help you determine the scope of the POC.

Questions to define the scope

The following questions can be used to define the goal of the proof of concept.

  1. What data should be copied?

    • Should whole databases be copied?

      • Which database management systems (DBMS) are involved?

      • Which databases should be copied?

      • Where should the databases be copied to? (Sandbox environment)

    • Should whole tables or sets of whole tables be copied?

      • Which database management systems (DBMS) are involved?

      • Which tables should be copied?

      • Where should the tables be copied to? (Sandbox environment)

    • Should datasets based on relational integrity be copied?

      • Which database management systems (DBMS) are involved?

      • Which tables should be copied?

      • Where should the tables be copied to (Sandbox environment)?

      • What are the criteria to select the logical data records to be copied?

      • How is the data be related in the tables?

        • Are there foreign keys in the database which relate tables?

        • Which columns of the tables are required to relate two tables?

        • Are there restrictions for the relations (relation is only valid if column x has a specific value?)

        • Are the data types of the columns in both tables are identical or compatible?

        • Is there a technical document describing the relations?

  2. Should data be modified during the copy process?

    • Which data should be modified (names, addresses, bank data, birth dates, IDs etc)?

    • In which tables and columns should this data be modified?

    • Do you plan to modify columns that are part of a foreign key relationship (either formally defined in the database, or as part of the application logic)?

    • How should the data be modified?

      • Do you have existing algorithms that you want to use to modify data? If so, in which programming language are these algorithms currently written and how are they invoked?

      • Do you want to use the pre-defined masking algorithms that ship with XDM?

      • Is there a certain order in which columns need to be masked because one column depends on the masked value of another column?

    • Where can the data be copied to test the modification?

      The target environment should be allowed to contain corrupted data during the setup process. For this, it must not to be the source at the same time.
      The target environment can be an empty database or schema with create permissions.

  3. Should data be ordered by a third person?

    • Should the third person be allowed to execute a data order directly?

  4. Should data from sequential files be used?

    • Should data be read from or written to VSAM or CSV files on a Db2 z/OS system?

    • Should data be read from or written to CSV files on a system different from Db2 z/OS system ?

  5. Should the permission management with several users be shown?

  6. Should an external execution of task be used (e.g. via Jenkins plugin, or API call)?

    Permission management and external execution are typically not part of a proof of concept. However, in case they are to be included, then the scope of the proof of concept will be increased, and it may require extending the duration of the proof of concept.

Technical requirements

Requirements to run XDM

Necessary requirements:

  • Requirements for XDM are fulfilled,

  • JDBC Connection to the databases is available,

  • Permissions to read source objects and read and write target objects are set for the users to work with.

Recommended requirements:

  • To copy whole tables fast:

    • FTP connection to the database servers is available,

    • Shared drive is defined, if it should be used.

Requirements for the POC

Necessary requirements:

  • Sandbox environment for the POC is available:

    • Tables exist or can be generated by XDM,

    • Data can be inserted and changed without impact to any application or team.

Recommended requirements, if possible:

  • Remote access (typically VPN) for UBS support personnel,

  • Direct access to the databases,

  • Direct access to the server.