Broadcom Test Data Manager's scalability is nine out of ten. 

It is a scalable solution. Go with a classic VM-based installation. You can do horizontal scaling, like adding resources, you can do that, and you don't need to have any downtime. But with the Kubernetes edition, you can have other vertical and horizontal scaling, and auto-scaling is available.

Scalability-wise, I rate the solution between seven to eight out of ten since there are so many systems and databases, and the scalability of the solution depends on them. But it does support a lot of databases and applications. Right now, there are three users using the solution in my company. Also, we don't plan to increase its usage.

TDM scalability has actually come a long way. I am really impressed with what they have done over the last couple of years for it. Specifically, what I really like is, as they moved from a thick line that was a little bit clumsy and cluttered, what we see now is that we have a web portal that is built on top of an entire API framework. Utilizing those APIs, it gives us a chance to do whatever we want with the tool, not just its specific built-in functions through the UI layer, but anything I want to do integrated with the open source abilities out there as well.

It has scaled for us very well. We're able to do small amounts of data and large amounts for performance testing.

The many databases supported and data delivery formats available provide a seemingly endless supply of options to meet the ever growing demand of our testing teams.

The solution - once it's in place - you really don't have to give a tool to the users. All you have to do is make it visible to them, so they can use it as a self-service solution, which is very helpful. You don't have to grow a team to have thousands of people. You could have a very small nimble team that does development, and then just propagate to everybody else to use with a click.

I cannot answer because we only did a PoC, so I have no idea how it will work, if there will be a couple of designers working with the stool.

Still, I don't see any kind of issues because there will be only a few people working with the design of masking and the rest will be done on the scripting level, so it's possible we won't see it at all. 

Scalability is similar along the SV lines; it's relatively easy to scale. It's a matter of how you want to set up your data distribution.

Within our organization we have many, many platforms, many, many different technologies. One of the interesting challenges we always have is in terms of, especially when we're doing performance testing, can we get the kind of the volumes of data in sufficient times, and we use things like data explosion quite often and it does what it needs to do and it does it very quickly.

For our platform, scalability probably isn't really an issue. We're not planning on using it the way it was intended because we're not going to use it for continually generating more data. We want to only generate specific output that we will then maintain separately and reuse. So, the only time we will generate anything is anytime there is a different test case needed, a different condition that we need to be able to create. So, scalability is not issue.

It is scalable. This particular tool is  used by certain types of engineers, TDM engineers. But the recipient of the tool can be anybody so it can be scaled for as many licenses as the customer is willing to pay for. It's kind of expensive.

We haven't run into any issues at this point. So far we think that we're going to be able to get where we need to. In the future, as we expand, we may have a need to increase the hardware associated with it and optimize some query language, but I think we'll be in good shape.

When we publish a lot data into the target, sometimes it is not able to handle it. What we do normally is we create the data margins of the source and we try to publish short sets of data into the target. Many times the publish will fail. I think the reason is because of huge sets of data that we publish. I am not sure if it is the tool issue, but I have seen this a lot of times before, where it is not able to publish a huge set of data (thousands and thousands of sets of data). With a few sets, it works. When we try to publish a lot of data, every time there is a publish error. Though, I have not tried it lately, we have seen this before.

It is not very scalable because even to generate maybe a couple of million records, it takes six to seven hours. If cloud muscle power could be included with it – like if the synthetic data generation can be done using a cloud instance; it's all synthetic data, so nothing is PII in it – if you could have a cloud feature where the data can be generated in the cloud, which might have multi-GB of RAM in memory, that would be great for us.

You can envision TDM happening at three layers. One is the application layer, the second is a cluster layer, and the third is an end-to-end layer. The data required for the first level and the second level are pretty different. You can't use first-level data in the second level. And the data required for the third, for end-to-end testing, is very different from the first two layers.

So when we look at scalability, we have to see how we are creating the "journey" from one layer to another. For example, if we are working in the customer area and then we jump to payments, we have to see what the common things are that we can scale and what areas we have not tested and address them.

It's a tool so scalability depends on you use it. Scalability is pretty relative. It provides a lot of features and it's up to you how you utilize them. It's pretty scalable. It has automated features and I don't think there is any other tool in the market which provides such a level of automated solutions. The demand in the industry, with respect to enterprise solutions, is pretty complex and CA TDM is pretty good. It is scalable but not to the extent that a foolproof enterprise solution can be provided using this tool.

The scalability is outstanding. We're able to scale it to any size of data that we want. We can do small data sets, we can do large data sets.

Broadcom TDM is scalable.

Scalability is a matter of how you use your systems. Our requirements required using it for MS SQL Server, Db2, and LUW Db2. We scaled the tool with all the databases we have, so it's scalable.

It scales very well to our network. We have a very large network. Finding a solution that can actually monitor all the devices and interfaces, this product has been able to do that.

It has scaled tremendously. Especially, again, I don't want to harp back too much on it, but when you start looking at data generation, your options are endless in the way you want to incorporate that into your environment.

I have my manual testers utilizing this to create data on the fly at any moment. I have my automation users who are going through a little bit more of it, getting daily builds sent to them. I have more performance guys sending requests in for hundreds of thousands of records at any given time, that might have taken them two weeks to build out before, that I can now do in a couple hours. It ties in with our pipelines out to production.

It's a wonderful tool when it comes to the scalability.

It is fairly scalable for the implementations I've participated in. We haven't yet utilized the current available capacity.

Yes, the product is quite helpful to suffice our data masking and synthetic data generation requirement.

I think one of the main features of TDM is how you can scale from a small organization; how you can use it in a very big organization. In our company, that is everything. Only because of that very feature, scalability, we are considering TDM.

We will see about scalability when we implement the product. We are just beginning the implementation phase. We are just about to install the product right now in the production environment.

I can't really tell you much. I can tell you about the integration, because we are integrating it with the Service Virtualization tool. Here, we are having a lot of benefits.

For example, we are starting to provide the data necessary to prove little pieces of code or small integration packages, and we have seen a lot of value there.

Scalability. It's good as well.

So far it has worked for our enterprise services, and we are pretty large. So, I would say it is fairly scalable at the moment.

We haven't had any issues so far, so I guess I'd say I'm comfortable with the scalability right now.