The initial deployment was a bit complex. It is straightforward now. We have migrated from SQL, Oracle, and Google Cloud in the last five years. 

The initial setup is straightforward. There is a wizard, and one needs to click it and set up the solution. And you can run it on a desktop machine; there is no need to have high-end servers to run or install it. The good part is that it has a Kubernetes edition, which is amazing. If you look at the trend, there are many tools you need to place on On-Prem, or there could be a SaaS version also. But Broadcom TDM has a Kubernetes edition so you don't need to consume a lot of cloud infrastructure. So as and when there is a demand, it can make a scalable number of forwards and do a Kubernetes scalable masking, which I don't think any other system in the market delivers these kinds of options capable of. As TDM is delivering a Helm Chart so, once the prerequisites are ready, it just takes a few minutes to deploy it. For the deployment, the main thing is taking role-based Control, and there is a dedicated guy. We can have for creating definitions for data generation and sub-setting, you can have a dedicated guy for creating the masking definitions as well.

I would say that the initial setup is not that easy, but it's not that difficult, either. An average level of complexity is involved in the setup phase. Installation doesn't take time. However, installing, like, a full-fledged data management solution can take years, depending on the organization and complexity. Regarding the deployment process, we started the data masking, and then we moved on slowly to synthetic data generation and data subsetting. So, these steps could be difficult to elaborate on because it depends upon the organization's requirements and what they really want to implement.

The staff required for the deployment to maintenance would really depend on the organization. But typically, it should depend on a minimum of three to five resources, and then it can go on based on the requirements.

CA and one of our vendor partners came in and helped us do a Proof of Concept. They helped set up the infrastructure, and then walked us through the application, and actually proved out that we could do in in our environment, because it was, for us, an interesting environment. It was, I wouldn't say easy, but we were able to get it done.

I didn't do the setup by myself, it was done by a person from CA. It didn't look hard. It looked pretty straightforward, even with configuration of the back-end database.

The initial setup was done internally. Obviously, the instructions that were online when we downloaded it, we were able to follow those and get the installation done. We did have a couple of calls into the technical solution support area and they were able to resolve it fairly quick.

We've had the tool for about four or five years now within the organization. As you might expect we first got the guys in not knowing anything about the tool and not really knowing how to deploy it, therefore what we needed to do was we called on the CA guys to come in and really to show us how the tool works, but also how to manipulate that within our organization. We had a problem case that we wanted to address, we used that as the proving item, and that's really where we started our journey in terms of a dedicated test data management function.

The truth is that I was involved in setup but they didn't listen to me. "They" are other people in the company I work for. It wasn't CA that did anything right or wrong, it was that the people that decided how to set it up didn't understand.  So we're struggling with that, and we will probably transition over. Right now we have it installed on laptops, and it shouldn't be. It should be server based. We should have a central point where we can maintain everything.

So, the set up is fairly straightforward, except for the fact that there are three steps that we have to go through. We have to do a pre-setup, a pre-process, then we can do our generation of our information, and then there's a post-process that we have to perform, only because of the unique characteristics of our platform.

It was good. There were some issues. It wasn't as smooth as we had thought.

We ran into a network issue, a firewall issue, things like that. It wasn't something we could not fix. We worked with the CA support and with the client's team to fix it. But there were issues, it took a lot of time to install and configure.

The setup was pretty straightforward.

The initial setup is always complex. I have been working in testing environments for the last 10 or eleven years. From what I have seen, most companies lack the basic building blocks for testing.

Suppose I have a system, and that system gives data to system Y, and Y gives data to system Z. Nobody has a clue how that data gets there for testing, because that end-to-end testing has never happened. We cannot give someone data which will be rejected from system Z. We have to give him data which will pass across all the systems. And that means we have to understand the mapping file behind it. However, the mapping file is often not there so we have to create it.

We have to talk about the various models, are they logical or physical? Somebody may have created a set of logical data models 20 years back but it is not usable now. We have to work with the tool to create that set of data.

We also have to consider the scheme of values. If it's IMS, that is different from RDBMS. We have to find out what segment has more data, which segment is completing and which segment is giving data to systems. When we talk to the people who are working on that data set, one that is 20 years old or 30 years old, 90 percent of the time they don't have a clue. They are working with various tools but they don't have a clue how it is happening.

So there are always multiple challenges at the start. But then we do due diligence for six or eight weeks and it clears up all the cobwebs: What is there, what is not there, and the roadmap. That puts a foot forward so we cna say, "Okay, this is how we should move and this is what we should be able to achieve in a given timeline."

The initial deployment will take a minimum of three to four weeks.

The second step is a PoC or a pilot to run with a set of use cases.

The setup is of medium complexity. It's been a long time since I set it up. I have had it on my laptop for a long time, but this is what I remember. The configuration does not happen by clicking a button and then you can start using it. It has its own steps. You register the depository, etc., to get into the tool. The installation itself is fine, but configuring it and getting it ready to use could be better.

The time it takes depends. At times I have installed it in a couple of hours, but if I get stuck... I don't remember all the issues I have faced, it's been a while, but I do remember that I had issues.

Every project and every implementation have to have a strategy. There are a few basic things that we look for and we follow a checklist to see if the project is feasible for TDM or model-based testing or some other solution. As far as implementation strategies are concerned, they are very specific to the client and the kind of ecosystem the client has. The basic strategy would be to not go "big-bang," to start with the basic and medium-complexity tests to show the ROI, and then roll it out one-by-one across the enterprise. But there can be a lot of nuances in the strategy document.

In terms of the number of staff needed for deployment, to start with we would not need more than two people to perform the PoC and do due diligence on the requirements. We would need two to three people in a bigger organization and one person for a smaller solution It depends on the requirements and on how much work is involved. To maintain it, one person should be enough.

The initial setup was challenging, and I would rate it 1.5 out of 5.

The initial setup was straightforward. One of CA's consultants came to our company and did the installation in about two days. We use mainframes here, and mainframes are very complex. Still, the consultant did it in two days.

Due to our environment, it was complex. The product itself is simple. 

It's a great package that they have out there. It's a plug-and-play kind of system, so it executes well on its own to get up and running in the first place. When they do send releases in, it's as simple as loading the new release.

What's kind of neat about it is, if they do have something that needs to be upgraded on an extension of the system, some of the repositories and things like that, it's smart enough to actually let you know that needs to happen. It's going to shut it down, take care of it itself, and then rebuild everything.

Initial setup was complex in comparison to other solutions for which we did proof-of-concept. There are a lot of contact points with the TDM suite, which I personally felt increased the complexity.

Initial setup was pretty straightforward. We just require a license and a native server, after installation the product will be available for all users under the server.

We are here to buy it, as I’ve mentioned, but there was an initial setup to do the proof of concepts. I was involved in it with some of their technology people.

It was easy I think because of the experts who were there. They know how to interact with people who don't know the product. When we evolved through that product knowledge, I think they also took us through the journey. It was very easy to interact with them.

The initial setup was straightforward. Basically, just install, next, and start using it. I figured it out right away.

The initial setup was complex, because it is new to the company as well as new to me. It is a new role for me, so building it from the ground up certainly makes it complex.

I was not involved in the initial setup.

Initial setup was pretty straightforward. We had one user that was primarily working on it. She probably spent a few months initially setting it up, but it is just because we do not know the product. We did not know it at first, and working out all the kinks to work with our environment.