DX Spectrum Reviews

It's primarily a fault management tool.

An organization using DX Spectrum is more easily able to understand the root cause when something happens in its environment. The tool gives you the ability to correlate all the alarms from different devices and areas. You can pull the information together and you have a really good picture of what might have caused the problem, and what you can do to prevent it from happening the next time. That's a huge benefit. 

It also reduces the amount of time it takes to troubleshoot a problem.

The Global Collections are what I found to be most valuable. With the Global Collections, you're able to organize and categorize devices into "folders," or functional groups and categories, so that it doesn't matter which SpectroSERVER those devices are on.

In this tool, there's a distributed setup and you can have multiple SpectroSERVERs. Normally the devices that are on a SpectroSERVER are local to that SpectroSERVER. But with the OneClick Console and the Global Collections concept, you can take devices from any SpectroSERVER and put them in a group. You're then able to manage those devices from the Global Collections, which span across your SpectroSERVERs. That's one of the most valuable features of the tool because it allows for really efficient management of your devices, especially in a really large distributed environment.

Another really good feature is what's called SANM, the Spectrum Alarm Notification Manager. It allows you to produce notifications based on certain things that are happening. Each SANM notification runs as its own individual process. If one SANM notification stopped working for some reason, it wouldn't affect all the other ones. That's a really good feature as well.

One thing I would like to see improved is that it doesn't really allow for multi-tenancy. If you're an ISP or an MSP and you want to use this tool to provide these types of fault management services to your customers, you would need a separate SpectroSERVER for each customer, and probably a separate OneClick Console. You would almost need a separate instance of the tool running for each customer. Whereas other tools have multi-tenancy built-in, out-of-the-box, and you can stand up one instance of the tool. They should definitely try to change that to make it multi-tenancy-friendly because it's not at all.

They could also improve how events are managed and correlated in the system. They need to make event management and correlation something that works from a group perspective, versus having to go into all these files and manipulate certain portions of a file to effectively manage events. That should be something that comes through in an interface.

I started using DX Spectrum around 2007 or 2008. That's when I took my first Spectrum DX class. At that time, it was version 8.1.

My first time using it was as a consultant for a pretty large consulting company. I set the tool up for different organizations and businesses. That included installing the tool and discovering devices in that company's network, and then organizing those devices into Global Collections, organizing the maps. I also ensured that they were able to see all of the alarms on the OneClick Console, alarms that they needed to manage their devices effectively. I would also optimize all of the alarms and all of the company's data and resources so that they were not being overwhelmed with alarms.

It's a very stable and mature tool. It's been around for a long time and has gone through all the changes the industry has gone through. It's rock-solid. I don't recall any bugs that prevented the use of the product.

It's not easily scalable. To scale out, you have to install more SpectroSERVERs in the environment. That connects to the multi-tenancy topic. I wouldn't consider it the easiest product to scale out. That monolithic-type architecture is prevalent in legacy-type applications. That makes it difficult to scale, especially in today's environment.

It is used across multiple locations, departments, and teams. It really depends on how a client wants to deploy their SpectroSERVERs and where they want to put them. The environment depends on who is using the solution and how big their deployment is. But you could have hundreds of users in the system. I'm not even sure if there's a limit on that. Most companies did have a lot of users. They were pretty much all enterprise-level.

The tech support was really good. It depends on who you get, but most of the tech support people I worked with were pretty sharp and would help you resolve the problem pretty quickly.

Positive

I did use a performance and fault management tool, but that is a really old solution. It was a tool built by a consulting company called INS, going back to the early 2000s possibly.

Another tool I used was something called Infovista, which is a suite of tools, so it has more than just fault management. It was primarily for performance management.

The initial setup is fairly straightforward. You have to know all the steps, obviously, but I can do it in my sleep now.

To install it and get it fully functional takes about a week. That sounds like a long time, but the optimization piece is what really takes the longest. To get it installed and have some of the basic, out-of-the-box stuff working would take a day or two days. The optimization piece could take anywhere from three or four days to two weeks, depending on what the customer wants to see. 

Clients would normally go with a OneClick Console and three primary SpectroSERVERs and then three backup SpectroSERVERs. Each of the primary and secondary pairs works in tandem. They communicate with each other.

Each SpectroSERVER pair can be thought of as a separate entity. Within each pair, they work together, such that the primary does the data collection, correlation, and polling. It sends its information over to the secondary and that's happening with each of the three pairs of SpectroSERVERs. 

The primaries are also sending your data over to the OneClick server. The latter has the ability to see all three of the devices and correlate things. The OneClick Console can be thought of as your web front-end, and then the SpectroSERVERs are like your database and polling layer. 

The number of SpectroSERVERs really depends on the size of the environment and what you want to monitor.

About 90 to 95 percent of my deployments were on-prem hardware servers. It then went to being on VMware virtualized boxes. Now, most of them are using cloud-based systems. The SpectroSERVERs are in the cloud.

Most of the companies using the solution have two, three, or four data centers with a SpectroSERVER pair in each data center. Or it might be set up with a primary SpectroSERVER in data center A, data center B, and data center C, but with the secondary for A in B, the secondary for B in C, and the secondary for C in A. That way, if a data center goes down, you still have some functionality for multiple SpectroSERVERs in different data centers.

Because SpectroSERVERs talk to devices, you want to keep them as close to the devices as possible, in that particular data center. You don't really want to do polling, monitoring, and management across wide area network connections. 

In terms of how departments manage the information, that's where Global Collections come in. You can make them either departmental or functional, et cetera.

In terms of maintenance, backups are done on a daily basis and that is something that has to be maintained. Replication between the SpectroSERVERs is something that needs to be maintained as well. There's a fair amount of maintenance that needs to be done on the product, but it's not to the point where you can't do anything else.

All our clients have definitely seen ROI. Although I haven't gotten specific information on that from customers, I would imagine that ROI comes because the time it takes to understand and resolve issues and get back to a fully functional state, is reduced significantly through the use of DX Spectrum.

I would definitely recommend it. With any tool, you want to do a proof of concept, but it's a great tool for fault management. Also, understand the caveats: that it's not the most scalable tool and it's not very multi-tenant friendly. Aside from that, it's rock-solid in terms of how it does fault management. That's something that you really can't beat.

In my mind, Spectrum DX was the number one fault management in the market for many years. Now, with everything moving back to the cloud, I don't know where it stands.

It helps our NetOps group actually handle alarms in a way that lets them see the bigger picture of those alarms, and how they might affect our services. It helps us communicate information about the network state better to services that might be impacted by a specific network condition.

Spectrum allows us to have a holistic view of our network architecture. We have a pretty heterogeneous topology at U of M, we're a half Cisco, half Juniper shop, and we have multiple layers to our network topology. So, it's really important for us to be able to do that topological map, and be able to visualize the network state at any given time.

Spectrum is interesting because it's a super-mature product for CA, and it works really, really well the way it is. In terms of new features and functionality, I feel like there has to be a transition there. The Spectrum OneClick is a Java-based client, and that's aging. Really, before any new feature integration, I'd love to see a comprehensive rebuild of the UI.

It's pretty stable for us. We have, not a highly available implementation of Spectrum, but we have an active standby situation, where we have an active SpectroSERVER and a standby SpectroSERVER and an active OneClick and a standby OneClick running all the time. So it works out pretty well that way.

As the kind of enterprise that straddles the line between telco size and enterprise size, it scales for us, because we're not all the way at telco yet. Maybe one day.

Pretty good. They're super responsive. They have that four-tier system and that works pretty well, because if we have a question, we can ask it at a lower priority and it will still get answered. If we have something where our hair is on fire, they'll call us right away.

It could be a little bit better, to be honest. The upgrade process could be smoother. More of the steps around upgrading could be automated, I think.

When selecting a vendor, the most important consideration is product; it has to be product and features.

I'd give it an eight out of 10 right now, because it does what we need it to do. It could go an extra 20 percent somewhere.

I use the solution for monitoring and configuration management. 

The tool is very mature, and its valuable features are monitoring and configuration management. 

From a functionality perspective, the product is not doing what it should. Also, there are some concerns about the accessibility. I would appreciate additional out-of-the-box troubleshooting scripts, like templates for addressing various issues. Currently, when troubleshooting online, I need to create my scripts. It would be beneficial if the platform could provide pre-built scripts or templates to help automate certain troubleshooting tasks.

I have been using the product for eight years. 

I rate DX Spectrum's stability a ten out of ten. 

I rate the tool's scalability a ten out of ten. I can scale it for hundreds and thousands of users easily. 

DX Spectrum's technical support is good and responsive. 

I have used OpenText before DX Spectrum. 

I can complete DX Spectrum's deployment in two hours. 

DX Spectrum's pricing is neither expensive nor cheap. 

I have my own script to analyze the data and perform actions in the backend, like repairing a configuration. I rate DX Spectrum a nine out of ten. 

I have used Spectrum with four or five customers that are reasonably big. Some of them have an infrastructure that covers more than 30,000 desktops. 

If you are looking for the right monitoring tool, Spectrum is one of the best solutions. It covers networks very well. It has all the capabilities that you're looking for when it comes to monitoring. Spectrum is great for root cause analysis. It has excellent correlation event management. Spectrum's stability and scalability are also amazing. If you have a CA Service Desk, then it can be integrated so that if you have open tickets they can be closed automatically. The configuration manager is great as well. 

It's not a great performance management tool. Its reporting capabilities are not very good at all. 

I've used DX Spectrum for over 17 years.

It's a very stable product.

The scalability is there and architecture-wise it's simple. The interconnectivity is amazing.

CA Broadcom support is very bad—one of the worst. They are trying to improve a little, but right now, they don't even respond to a ticket for at least a couple of days. A customer is spending $100,000-200,000 on a product, and it takes them three days just to respond asking for the version number. And after the acquisition of Broadcom, it's only gotten worse. 

Setup is easy and pretty straightforward. If you have a simple architecture and everything is already together, it will only take a couple of hours. If you have an architecture that's more complex, then it takes only one day or two altogether.

In-house. The job generally requires at least two consultants for the implementation side. If it's a big customer you require at least two consultants to implement. For smaller and medium-sized customers, then one consultant is more than enough to implement this.

They are mostly on a perpetual license, but some of them are now moving to a subscription. 

If you are looking for better performance management, then you should supplement DX spectrum with another tool like CA Unified Infrastructure Management.

I would rate it an eight out of ten.

We use this solution for monitoring both service provider networks as well as customer WAN / LAN / VOIP networks, including all kinds of SNMP-based edge devices.

The key solution to be solved is the correlation between all types of messages from all devices. We are receiving more than 1,000,000 SNMP messages a day across many types of domains.

Unifying the solution within our organization created a standard way of working and integration. We needed a centralized redundant solution for all of our domains, which requires an SNMP-based monitoring tool.

We were able to standardize the internal processes across all internal departments, resulting in almost an elimination of non-standard process flows through our organization.

We were also able to standardize by cross-learning from all teams on how we should configure the monitored elements, align the configuration of the monitoring application, and use the solution such that it created a common understanding of the best practices.

By implementing the automatic service incident, a very strong closed loop is created in the monitoring of the domains.

The topology correlation for layers one, two, three, and four significantly reduces the number of false positives (>98% ratio). By using Spectrum, we did not need to configure the network knowledge about redundancy. Rather, it learns the latest correlation between the monitored elements automatically.

By adding the alerting from the Broadcom performance management tools, a comprehensive list of alerts is created.

As a service provider, we added views for our customers to inspect their sub-domain in our whole network, which reinforces a high level of trust within the relationship to our customers.

This solution is missing the in-depth SDN correlation due to the late arrival of Spectrum VNA features and supported SDN networks. The various setups of the SDN networks are not always supported (yet) by the Spectrum VNA engine.

Integration with non-Broadcom AIOps solutions is a known area. We want to make our own choice for the AIOps solution and do not want to be forced to use the Broadcom OI solution by default.

For our size, a redundant based docker platform should be supported for large scale environments with more than 80,000 devices. This will have a very strong positive impact on the effort we need to spend in maintaining our large scale Spectrum solution and the related cost. The time to market for the new Spectrum solution will be reduced dramatically if this becomes available.

We have been using CA Spectrum for more than 15 years.

Stability is good, especially for large scale location redundant solutions with more than 80,000 devices in a single cluster.

In general, the location-redundancy with automatic failover is a myth, except if you are using Spectrum. If you setup spectrum in a redundant setup across 2 location (80 km in between), you can have a automatic fail over time within 10 seconds. This simplifies the maintenance of your setup a lot as well: any component can be switched off for maintenance purposes. The redundant instance takes over within 10 seconds.

Scalability is very good.

The support depends on the complexity of the problem. Because our own knowledge is quite high and our environment is quite huge, problems can be very complex and time-consuming to solve.

We used several solutions prior to this one. The reason we switched is that the combination was causing a problem and we needed to standardize.

You do need a decent level of knowledge to roll out this huge scale solution.

Small, single location-based solutions for 10,000 or fewer devices are relatively simple.

In our experience, the OOTB settings are very usable.

We did implement this using our own in-house Spectrum specialists, which do have knowledge that is on the same level as the first line support at Broadcom.

Our ROI is realized through better NPS and a smaller labour cost.

In general, the license cost will be about 30% of the total TCO for this tool (hardware/support team, OS costs, and OS management). It turned out to be cheaper than other solutions, even those in the public domain.

We evaluated IBM Netcool, different public domain-based SNMP solutions, HP OpenView NNM, and SolarWinds.

We hope that the speed of the improvement and product growth will soon again be at the same level as when this was a CA product.

• Network Configuration Manager
• MPLS & VPN Manager
• Southbound Gateway
• Event Rules
• Event Procedures

By using event rules and procedures, we got an improved event management process. CA Spectrum is very useful for event handling and brings us a robust “manager of managers” console.

SpectroSERVER fault tolerance (FT) functionality: The OneClick console should have a native HA or FT functionality. Actually, the only way to get this is by using a load balancer.

SpectroSERVER is the core component in CA Spectrum architecture which polls devices into the network. You can use multiple servers to build some kind of "cluster" to provide continued device polling when some server fails. A OneClick console (web server) is front-end of CA Spectrum, and it does not have an option to provide continued user access when a OneClick server fails (High Availability). You can use a Load Balancer, but is very expensive.

We have been using this solution for seven years.

SpectroSERVER and reporting databases can grow quickly. If you don't take care of trap storms, this can cause SpectroSERVER crashes and performance issues in the reporting.

No scalability issues were encountered.

Customer service is very good. I would give them a rating of 10 out of 10.

The North America technical support team is excellent, 10 out of 10.

The LATAM support team has some things to improve, six out of 10.

The initial setup was complex because it requires a deep knowledge about tool architecture and proprietary software. In some cases, if you make a mistake during the installation or the initial setup, the better solution is to reinstall or reinitialize some DB.

We implemented the solution through a vendor team. Their level of expertise was high, nine out of 10.

Licensing is usually expensive, but cost efficient.

We evaluated IBM Tivoli Monitoring.

I recommend the use of CA Spectrum mainly to monitor network infrastructure. Use this tool like a “manager of managers”. Event monitoring is a very powerful functionality.

If you want to monitor servers, apps, and databases, then use CA UIM probes.

For me, as a deployment person and support person for the product, the most valuable feature is the scalability of the product. We started out with a fairly ambitious goal of managing about ten thousand devices. That over a couple of years became about one hundred thousand devices. Without completely crashing our original architecture, we were able to scale up to meet that requirement rather easily by just horizontally adding more servers.

It met a really critical need inside of my company because just before I was hired, they had about a two-day outage in one of their data centers. They didn't really understand the scope of the outage because they lacked in their existing monitoring environment the ability to see the topology of the network. They thought they were fixing the problem over here for a couple of days until they finally realized, oops, they probably really made it worse. So that is one of the key things that Spectrum brings to the table, that ability to do vault isolation, and alarm suppression, and more quickly find and focus on the area that needs to be fixed.

A big problem for us now is the Java requirement for the console. It really should be using HTML5. Our personnel use a multitude of enterprise and network management tools, each of them with different Java requirements. They, as cleverly as they can, have devised a means of trying to make those things sort of work and play nicely together on their glass. But it's an issue. Every time we do an upgrade, the Java version changes for Spectrum.

The new web client is a fairly basic sort of operator-level solution at this point, but it's going to expand into a full-blown one at some point. One of the questions that I'll have for product manager is, what's the timeline for replacing Java?

From time to time we have issues with Spectrum. When we do, they are generally easy to recover from. I am very impressed with the stability of this product. I've been doing network management tools a long time and I know of what I speak.

In Spectrum, the concept is really two tiered. It's a solution with a web client application. Initially, we had nine servers doing the polling and, I think, two one-click servers serving the buoy. Then management came to us and said we need to do a whole other part of the enterprise, so add another nine servers. We just quickly added them and pointed them to the devices and the main location server, which is the one that ties all of the polars together. As more users were added, we just added more one-click servers.

I think we are one of the larger Spectrum deployments in the western hemisphere. There are some things we would like to request for product enhancements in terms of supporting a horizontally-scaled set of one-click servers.

I was very excited to see the presentation yesterday that told us where they think the product is, where it's going, and we are going to hear more of that today with the roadmap presentation. Things are looking very good.

It has been very, very good. We sometimes have to more carefully explain our problem to the person that is assigned to us. But once we get that fully understood, we quickly get the right focus. I have been very impressed a number of times with the quality of the person on the other end of the phone. They've actually helped us with some things beyond the actual current problem when they've taken a look at our system and said, oh by the way, do this or do that. It has been very good.

Installations went smoothly. Customizations were pretty straightforward.

If you like to sleep at night and not be disturbed on the weekends, get Spectrum. It's a really robust, mature product, but still with newer and newer features being added, and it's very, very stable.

Network monitoring is the most important reason for using it. It is deployed on-prem in our data center.

The visualization of the network topology is very good. The network operation guys get a much better understanding of the topology of the network. When something fails, it is easy to see who are the neighbors of the devices and what is impacted. This respective correlation is very helpful in limiting or pinpointing a problem.

The capability of handling and monitoring with SNMP and working with the SNMP traps is much better than other products.

There should be better integration with other Broadcom products, like network performance manager. Currently, for every part of a product, you need a separate server environment. You have something for Spectrum, you have something for network performance, and you have something for NetFlow. There are a lot of islands and server farms with different technologies. They should be redeveloped to get one platform for all.

I have been using DX Spectrum for 20 years.

It is stable now. Over 20 years, we have seen a lot of crazy bugs, but in the last two or three years, there are no critical bugs there.

It is absolutely scalable. It scales very well. We have more than 50,000 devices for one of our customers. It is very easy.

In terms of our environment, servers are deployed in two data centers. Our environment is divided. We have a central server farm, which is split up for our customers. So, we are sharing one Spectrum instance with multiple customers. Our customers are medium to large enterprises.

It changed a lot of times. It depends on the people who are working there. It depends on the person on the other side. For example, if you are routed to India, you could have some problems with the quality.

Neutral

We had NetView from IBM. We switched over to DX Spectrum because we were just flooded with events, and we had no idea about the root cause of the event. We tested the other solutions at this time, like HPO View, but they never gave us the view that we have in Spectrum now in terms of pinpointing where the problem is.

It's a bit too complex right now. From the point of DX Spectrum, you have to implement a lot of server components. It should be easier because a lot of automation is possible today in the market.

If everything is already prepared, you just need one day to deploy it. It doesn't take so much time. The implementation strategy depends on the customer or data center environment and the processes. With preparation, it takes about one month.

In terms of the staff required, you need just one person for the Spectrum piece, but of course, you need a few people for preparing the network, firewall rules, and things like that.

In terms of maintenance, the maintenance is that you have to keep it up to date. Other than that, there is not so much to do.

We see an ROI in the operational cost. We have a lot of automation behind the events coming in, and the operators get a very key understanding of what's happening. So, there is our return on investment. Our operations people are much faster in reacting to and solving problems.

Since the acquisition by Broadcom, we have not had such a good experience with licensing and pricing. Since they were bought by Broadcom, every sales contract is getting complicated. It's very complicated, and it's much more expensive than before. It's not a good pricing strategy from Broadcom.

I would absolutely recommend it, but it's not so easy to learn. It's not geared toward self-learning. It's a good idea to have a Spectrum partner.

I would rate it a nine out of ten.