reducing delivery times

When reducing delivery times by 90% does not seem enough

Towards the end of the implementation projects, it is common that we receive emails demanding that we should reduce even more the time of the segmentation process for the transferred structures.

“When you receive an email asking you to reduce delivery times even more, you know that the project has already been successful.”

At the point where the feasibility of the project is not questioned, but whether the delivery is fast enough, or could be faster, we know that we are dealing with the last arrangements. The icaria implantation task is already successful!

Our experience implementing icaria TDM to reduce delivery times.

In our experience, the implementation of a segmentation strategy within the company is usually done for the first time with icaria.

However, we found that some organizations have carried out very specific in-house projects for each subsetting application. They already know the difficulties and challenges of segmentation. And they anticipate benefits such as reducing the size of environments, repetition of movements or the delivery of isolated structures, without affecting the rest.

Given the complexity and costs of the above, it is not uncommon to find other simpler alternative strategies, for example:

  • Scripts that execute, mainly, queries on the databases involved to create relatively simple structures.
  • Automatisms to replicate the calls to the resource creation services, functionally replicating the client's applications.
  • Manual creation of the resource, completely by hand.

Of all these strategies, perhaps the last one is one of the most common. Anyway, it is common to find a combination of all of them.

Despite all this, once data segmentation with tools like icaria TDM enters the company, the previous difficulties and limitations are easily forgotten. What remains still is the possibility of moving structures in an agile way, with less dependency between teams, closer to the real data and with a lower error rate with respect to the type of requested petition.

Expected delivery times

At this point, the speed of the segmentation process begins to be questioned. But what times can be expected?

In relative terms, according to the data we have collected, the times are 90% lower than the previous processes, on average. We are talking, in most movements, of minutes, if not seconds. Only in the case of extremely complex and large structures the movement can take a few tens of minutes, these movements move hundreds of thousands of records that are widely spread throughout the segmentation tree.

What if we see some real examples of how to reduce delivery times?

reducing delivery times

From several days to tens of minutes

Structures that require several days to replicate in test environments are now transferred in a matter of minutes, with maximums recorded of about 90 minutes for the most extreme cases. Also, in this example, the size of the move is now reduced from the previous solution allowing you to filter the structure by moving only the data of interest. All of this can be configured by the petitioner to choose which strategy suits them at all times.

Thousands of structures in a few minutes

Thousands of structures in a few minutes

Movement of the client set, account and other bank data, of the order of 50,000 structures, in less than 30 minutes. Previously this move was not directly replicable; it required the replication and subsequent segmentation of the entire database, with all the negative implications that this implies.

Moving an entire sub-organization in a matter of days

Moving an entire sub-organization in a matter of days

Movement of all the clients of a sub-organization, approximate magnitudes of 5 million clients, in about 96 hours. All this while the environment remains available for other tests. Also allowing the repetitive movement of customer batches for those tests that fail.

Reducing processing time by 90% is not enough

Returning to the initial question, there comes a time when all the previous challenges have been forgotten, the complexity of the process or the number of records that are inspected per movement are forgotten.

“The transfer of a client can affect more than 20,000 records. They must be inspected in an orderly manner and treated meticulously. In these orders of magnitude, the process can hardly take a few seconds.”

And despite the above, greater efficiency is claimed. It is understandable that, once the segmentation strategy comes into play, the development and testing teams usually think of new ways to exploit, use and test this information, the demand increases.

In the second part of this post, we will tell you at a technical level how we deal with this issue for which, on many occasions, the simplest thing from our perspective would be to improve the performance of the databases involved in the transfer process.

If you want to reduce time and improve the quality of your tests, request a demo now at this link.


You may also like:

Protection of personal data and TDM, how to make a viable fit?

How to apply data dissociation in test environments?

How to automate TDM to gain agility and quality?