Broadcom DX Application Performance Management Reviews

The feature we've found most valuable in our daily use of it is the deep-dive analysis of Java-class transactions performance.

It's important that our managers are able to measure the SLAs of our applications. They're able to do that with APM as it provides both real-time and historical performance data so that adjustments can be made accordingly.

The biggest area of improvement of APM is with the GUIs. Many of them are quite clunky and dated. For example, there is the thin client which doesn’t have all functionality, and then there's the thick client which has three different modes -- investigator window, management module window, and console window.

I've used it for 18 months.

We've had no issues with deployment.

We have had issues with APM's stability, but it is sometimes hard to tell if this is due to our virtual infrastructure or in the product itself.

We have had some issues with historical metric limits as the agents get load balanced between collectors.

In our experience, technical support has been excellent. They have very good turnaround time and very good technical knowledge.

The company has used a different solution previously, but I haven’t personally.

The initial setup is complex. It’s a large suite of products that need to fit into a large, complex organization.

This is not something I deal with, but off-hand comments seem to indicate that it is more expensive than expected.

Dynatrace and a few others were looked at by my team. I wasn’t involved in the evaluation, however.

Keep the deployed agents up to date in a large organization. You’ll need mature automation and configuration processes and techniques.

We are using APM for troubleshooting and because of this product, the delay to solve and to fix issues has been reduced by 40% on average. We also use the APM data to analyze and predict if an application will work.

For us, the application is a new eye on the same data. Its quality and the way we access it is going to make the difference between an application you keep using and an application you won't. There are a lot of DevOps methodologies to improve the time to market and to deploy applications quicker. Sometimes it's not enough because at the end, the application expands some issues and the isolation of a root cause is quite complicated. We analyze about 3,000 incidents and predictions, classify them, choose our toolbox, including APM tools (the CA APM solution), and we are able to predict, to anticipate incidents and to assess a risk for an application to go live.

An application is quite complicated in the environment of a software reliability engineer, because our applications are like a black box. Thanks to CA APM we are able to transform this black box to a gray box by using the transaction trace functionality services. For me it's the most valuable service of the solution.

The product displays some graphics and sometimes we want to have some different metrics in the same graphic but it doesn't display in the same scale, so it's quite complicated to see the metrics. If the product would be able to manage a double scale, it would be perfect.

We measure the limit of a solution by the number of users. The application is developed in Java and only 10 to 15 users can connect to the application. It's quite a limit for massive deployment in a huge company like Orange.

Our scalability is great because you can add servers. It works.

I don't use support, I do everything myself.

It was the only tool in 2006 to provide the transaction trace feature. As mentioned before, it transforms an application from a black box to a gray box, that's why we knew that we needed Introscope (now CA APM).

It was quite easy. The solution is easy to deploy and we had the support of a vendor team.

We deployed it on 5 or 6 applications and now it's deployed for over 200 applications.

If you have a large web firm or a group of servers, it does a great job of aggregating performance metrics into single viewable graphs or dashboards.

We're primarily using it for production-system monitoring of application errors, slowness, things like that. I identify issues for our customers.

It's a very manual process, I believe, in the current version that we're using, which is 9.5. So you have to spend a lot of time analyzing the metrics to determine what thresholds you want alerts on. For example, you want response time for an application. You have to baseline that response time and then develop your systems around those. Sometimes the baselining is more difficult because you have an expectation of a response time to be slower during some periods of times than others, and you don't want to set off false alarms. So it would be great if that process did not have to be done manually.

There's a lot of improvements that could be made. I think the newer versions that are coming out go a long way towards that. Back to the baselining thing, there's a lot of automated baselines now, and they provide differential analysis of whether or not something's going wrong as compared to how it normally should be running.

Also, it could use better views into the system, of a transaction flowing through the system.

It takes a long time to get it set up and configured in your applications and running. And out of the box, what I have found is that when you take the system, if you just drop it on your application, the overhead of the agents and the monitoring and the collection of all the data is out-of-the-box, and it's too much and will impact your application. So, what we have done, in the most recent deployment, is gone to a very scaled-back version of the application and sort of added in until we were satisfied that we were collecting the data that we needed, and balancing that with not impacting the application to the customers.

For the most part, it's been stable. It's an agent product, so there's agents out on the servers. We've found that they run in services. There has been situations where the agent will disconnect or things like that, and then we're not getting metrics until someone notices it.

I'm using it primarily for our front-end websites and our mobile-banking sites. So we're probably running 250,000 clients through the system.

Technical support is really good. I'm very happy with them.

It wasn't my decision. When I joined the company, they already had it, but they weren't using it. So, some of the applications that I was responsible for, I saw that we could leverage it and so I began using it.

When it was stable, Trending Reports and Response Time Distribution

Cultural issues prevent a product like this from making the impact it should have.

Stability

4 Years

No

Yes

Yes

Poor-fair

Poor-fair

Straight forward for technically competent people.

Minimal

No, it was part of a Business Partner larger purchase.

Java-based enterprise application servers monitoring: for example, WebSphere Application Server, JBoss EAP, WebLogic.

• User-defined transaction profiling
• Application topology discovery and visualization
• Application component deep dive.
  

It should enable you to see the usage and performance of all application dependencies like databases, web services, caching, etc.

• Root cause detection
• Easy installation and configuration
• It should facilitate real user monitoring to see what your users are experiencing in real time.

We are a solutions provider. Obviously, depending on the customer, we are monitoring applications. 

We have deployed to several customers and they have all found benefit in seeing how the application is performing, what components are performing worse, and where they can improve. DevOps is definitely a big play for us. 

They are seeing that benefit to having the APM product instrumenting their applications and getting that insight before it goes to production. It is working well.

Our development cycle has definitely improved as far as the turnaround time on fixes and improvements. The solution that gets put out is definitely better because of it.

• The ability to see which component is problematic. 
• If they are meeting SLAs before it gets to production impacting customers.

I know they are working on a more dynamic agent that will be able to evaluate the application and instrument based on what it is finding. I think that is fantastic. 

Getting that agent deployment simplified would be an amazing thing. The upcoming changes for the deployment process of the agent will help a lot, in that others have gotten to that point first.

It is stable. There are enhancements that we have to make sometimes that are not necessarily easy to implement depending on the customer and the situation. For the most part, it is a definitely a solid product and every customer definitely sees the benefit in using it.

One of the biggest challenges was trying to gauge overhead of a particular customer, and that was difficult to do. I know they are making improvements to the product to help address that type of situation. However, we are still in play there. There is benefit to it, but it was just difficult to prove that it was not the agent. With any situation like this, it is not uncommon to have your development team look at monitoring as a potential roadblock. Ultimately, I think we are low overhead and providing value to the development cycle.

I think other products do have a little bit more flexibility in how large they can scale. For the most part, I think every customer I have observed has been able to work with the product. Either way, we have options to scale. It is just whether it is one cluster versus a couple of clusters, and they get what they need.

Technical support is good. They are responsive, and always willing to help you. The turnaround time just depends on the issue, which is understandable. They have always been responsive with great people.

Where I started with the company, we were seeing outages daily. No one could really track what the problem was at the time. 

Since implementing this solution and having that information, the data to work off of definitely reduced that to basically nothing. It is custom code, so it is definitely a little difficult compared to some others, but it definitely helped us. For the most part, we run constantly without any issue at this point because of APM.

The initial setup is pretty easy; nothing complex.

Not necessarily. Since then, we have evaluated others and they all have their strong suits. APM still tends to do a more thorough job where others may have simplified the deployment process. 

CA APM still has a strong place in the market.

You need to really evaluate the data that you are getting and what is important to you. Where one product may do a really good job in providing visualizations and that sort of thing, are you really getting the level of depth that you need from your product? Just take the time to evaluate the quality of the data you are getting.

I like to see the vendor who is committed to your success, primarily. That they have a solid product, which I think, for the most part, most do. Also, they understand that the need to stay with you throughout the process to make sure you are supported. I think CA has always done a good job with this.

The ability to monitor real time customer experience and to correlate the performance degradation back to system events. The ability to measure customer/user impact during outage and to assign a cost impact to the “outage”.

Prior to the product, we only measured user/customer experience when they actually reported the issue however now we have the ability to understand user/customer experience when it takes place or even predict it with appropriate metrics. This means we can respond proactively when service is impacted without disputing/denying user/customer complaints.

Linking the business transactions back to the backend systems, in other words properly following and mapping the business transaction through the entire backend environment (Webserver -> Application Server -> SOA -> Database -> User).

6 Years

No, however I have many years in this space. I do however know of other implementations that were not as smooth.

The CEM (Customer Experience Management) product is still immature and do have hiccups. Most of the time it is very stable with an occasional glitch.

Yes, but this was related to infrastructure capacity. We could not expand our infrastructure how ever we exploited the product beyond its original design (so self inflicted).

Professional and helpful however I got frustrated many times due to their level of expertise. When we experienced issues with the product or had questions, we rarely got quick and proper answers and had to figure it out ourselves (we found that we had more “working” experience)

Yes, we used open source utilities. We could not scale the open source utilities to manage our enterprise applications.

The product setup is straight forward, however then you need to understand the business transactions and expectations to align the requirement and expected results. You also have a very good understanding of APM else you would not be able to link the expectation and product capability. I have handed this solution over to individuals who knows the product very very well and they fail to deliver as they do not comprehend APM.

Interesting question as I was part of the 3rd party vendor who did the implementation at the time. So let me refer this back to my previous comment. If you do not have an implemented (vendor or in-house) who understands the concept of APM and who to derive business value out of it then you have a problem. Making the product work is one thing…..

Hmmmm… Huge J!

We had a strategy that we realised over a period of 10 years which means that we introduced certain elements piece by piece, we did not deploy all at one go. It is however a very expensive outlay and I am currently reviewing the strategy due to our annual maintenance that is becoming very expensive.

Yes, we also looked at Dynatrace

This is not a IT initiative alone but a IT/Business partnership. This is not a IT Operational deployment alone either but a joint venture with the application developers as well. If these three parties collectively approach this tool then you will have proper ROI, else you will not realise the true potential and then it becomes a very expensive monitoring tool (which it is not - if you think it is a “monitoring” tool then you are looking at the wrong tool).

Application teams gained visibility into application performance. CA APM improved our ability to troubleshoot application issues and shorten resolution time.

The deep-process instrumentation gave us an opportunity to understand application process performance in detail.

We are using an old version of the product and I see a lot of improvements in the new release: better interface, and the ability to run predictive analytics.

The infrastructure is stable and scalable to the recommended capacity.

Customer service and technical support are very good.

We chose the CA APM solution several years ago for the set of features and the stability of the company behind the product.

The initial setup was straightforward.

We had a POC with the vendor before the implementation. That helped with better understanding of what to expect from the tool and the tool implementation.

It is difficult to measure ROI for the implementation. We has an ELA with unlimited licensing.

CA APM is a good product and I would recommend it. It might be specific to our company, but adoption by the application development community was not easy. I would recommend a dedicated team of APM SEMs to champion the APM implementation effort.