Dynatrace Reviews

My primary use cases of this solution are to understand how users are interacting with and experiencing applications and to quickly identify and fix problems.

Dynatrace has reduced our total headcount in operations and the mean time to detect and resolve problems. As a result, those challenging offline times are much shorter, if not non-existent, because of this solution.

The most valuable features are session replay, which allows for full playback of a user's experience; the AI engine "Davis," which does problem identification; and automatic mapping, which gives a visual representation of how applications interact host-to-host or process-to-process.

An area for improvement would be security. In the next release, I'd like to see more network-centric capabilities - Dynatrace is good at the network level, but I have to leverage other network solutions and integrate with them, but a holistic approach including the network as a one-stop-shop would be great.

Dynatrace's stability is solid - it performs updates very often, so it's always the latest and greatest in a good way.

Dynatrace has phenomenal scalability capabilities.

The technical support is phenomenal - they have a call program called Dynatrace ONE, which is like a customer success program on steroids. 

The initial setup was extremely straightforward and fast. The deployment function was also super fast, typically just a few hours at most, with the right tuning.

When used appropriately and applied to the applications that are meaningful for businesses, the ROI is extremely high.

There's a perception that Dynatrace's value could be questioned, but this is down to a lack of due diligence on the front end. When done right, this product always gives good ROI and total cost of ownership.

Dynatrace is really good at keeping some infrastructure details and really good at the application level. I would give this solution a score of ten out of ten.

We use this solution for end-user experience, infrastructure monitoring, analysis of bounce rates, service calls to the database, root cause analysis, and problem management. For end-user analysis, I can monitor where the connections come from, the time, the number of navigated pages, bounce rates, and finally, if the usage was satisfactory or not.

This solution has improved our organization in several ways, including the speed of detecting problems, predictive maintenance, root cause analysis, and alert generation. We are also better able to understand trends with respect to user behavior like time zone connections, and the times when there is less usage of the system by users.

Our organization is too IT oriented. I think with Dynatrace, it has helped to bring value to the business because now we can speak using the same language.

The most valuable features for me are end-user analysis and problem detection. I am responsible for adoption, availability, and performance. In the case of adoption, the number of new users coming to the system is a good metric for management. For problem management, problem detection is a good feature to save time.

I have reported a bug where a CI was not reflected in the dashboard, yet it was detected in the problem management.

On the side of the end user experience, I would suggest adding a new service for analyzing the backtrace of users.

Also, I would like to see an option to export the dashboard to create better reports and avoid copy/paste.

In terms of stability, it is ok and we have had no issues reported so far.

We cannot properly address scalability yet.

Prior to this solution, we used Gomez. It was part of the original solution that was installed. We had many problems with synthetic monitoring because it was down most of the time.

The tools were installed before I joined the company.

There are long term benefits in using the monitoring tool. There is also strategic value added, as is the case of transforming the internal language of the technical teams.

Currently, primary use case for the usage of AppMon is what I will call our flagship applications across the bank. We have had it about three years. Adoption was over time, one app at a time. then more and more. All of our major flagship applications now have AppMon dashboards. We do have some SaaS, but that is because the applications are cloud-based solutions. The use case frankly is about improving monitoring, system uptime, and preventing of events. If you have thresholds set correctly, along with alerting, and all the other stuff, your operational teams can find things before the field even notices.

We have substantially lowered incidents in our organization. It is hard to really measure it exactly from a percentage of how many have been lowered. As a general statement, there is no question that the number of incidents and the duration of incidents have dropped. Even if we do get caught blindsided by some infrastructure failure or something, our ability to pinpoint the problem through things like PurePath have dramatically reduced incident time. Whether you want to argue about AppMon, SaaS, or cloud from a business value point of view, that is tangible even for our non-technical people at the bank. They get this.

• The threshold alerting is what makes the difference. 
• The PurePath stuff for deep dive analysis on problems. That is massive as far as having a benefit. 

The dashboard is eye candy, because it's just a screen. It looks nice but the thresholding and alerting is what makes it meaningful because we are a 24/7 operation. As you can imagine, 2:00 AM in the morning, you can't necessarily afford to have a bunch of people staring at glass. We have to have the mechanism of the alerts, which is tied into our others systems, like xMatters. That is how it works for us.

I do not know everything that is in the hopper. What I am about to say could already be in the hopper. I am learning more about so called 7.1, be it SaaS or AppMon. Setting up the thresholds and alerting, it is complicated to understand their use cases. In other words, as a business perspective, you want to say, "I want this to alert under these conditions." However, you have to translate that in terms of all the various settings in Dynatrace. Whereas, it would be easier if Dynatrace just had a button that said, "I want this alerting use case," and I just pushed a button, then it set the 17 values behind the scenes. That would probably be a more user-friendly way. It does not require the user to understand what a threshold is or even what the different intervals of thresholds are. It is just a black box. It is like, "I want this experience," and it just figures out what to set.

The product is evolving, maybe too fast; maybe it is a little bit fragmented of an evolution. It is sort of expected in a way because the company, in my impression, is spending a lot more money. It is a function of the fact that they are growing as a company and revenue is growing, so there is probably a lot more emphasis on R&D and different product development. My expectation is that over time it will become a more unified, stable product. However, generally, from the product itself, we have not had issues with it, like something that monitors the monitor. We have not really had to worry about it.

I have not been aware of any limitations. I know that the older version of AppMon, the so called classic version, had some limits on number of agents per server. However, those limits never really caused a challenge for our particular topology.

As our adoption was in its infancy, we had the physical Dynatrace guardians, local from local areas, if you will, in our city. That was like our support because they were physically onsite. As our own staff became enabled and just basically knew the product, we frankly did not really need support, unless it was a product defect or something like that. In which case, we had a team within our company that was the interface for them.

We have used siloed monitoring tools in the past. A lot of products have obviously been around for years, even before Dynatrace. Typically, they are technology or topology specific. You have got a certain operating system or environment which is the product of choice for that environment: different operating system, different environment, and different product. You will also end up with a whole lot of tools sets, even depending on if you want a synthetic use case, something like Foglight as an example. You just wind up with too many tools. Even this morning, Dynatrace's CTO talked about this very problem. I guess Dynatrace is trying to solve this with one-shoe-fits-all. Which as an organization, who would not want a multi-supported application product that can go across all the topologies, cloud, and everything else?

There was a product we used before Dynatrace. We are a big mainframe shop, so it was a mainframe product. It was really built for the IBM mainframe. Because we were heavily in mainframe and this is going back a few years now, that was the product for choice for mainframe. Then, with web-based solutions, all these applications, cloud, and everything else coming, we needed something else. I do not really quite know how it happened exactly, but somebody talked to somebody who talked to some Dynatrace person. Then, I remember actually going to the very first ever meeting where a Dynatrace person came on our site. They asked me to attend because I'm a big stakeholder and I guess it just went from there.

At the decision time, we did have a senior executive emphasis on the business that there just appeared to be too many incidents and we are a major financial institution with 40,000 employees in the field essentially generating revenue on practically a 24/7 basis. If one of the systems that they use is even down for 10 minutes, that is like $1 million lost. So, there were a lot of events and the timing was right. Whether that was good timing on Dynatrace's part, because we had a problem that we needed to improve, they came into our location, we had a marriage, and we have been with them since. 

I was involved in one of the very first implementations, but I did rely on an infrastructure team that did the physical installation and acquisition of virtual servers, as far as the agents and the nodes. I was physically involved on a team that wrote one of the very first dashboards. This is three to four years ago. It was more about just learning the product, frankly. I look back now and I can close both eyes now. At that time, it took some time getting used to it, but I would not call it overly complex.

There may have been minor things, but that was more our own people trying to understand it. We may have had it, such as, "Let's install this agent on this server," then it didn't work. Then, "Oops." You have to back it out, then three days later, put it back in. A lot of that is teething. I do not see that as a product limitation. It is just sometimes you don't necessarily know what you don't know and kick the tires a couple times. Now, whether the product could have maybe been a little easier? It's hard to say in hindsight.

I don't want to bring up Apple, but you can think of the Apple example. Apple has this idea that you just take it out-of-the-box and turn it on. That's it. That's your extent of configuration. Dynatrace isn't quite like that, but probably for a reason, because the idea that it could just work as is doesn't make sense, because the individual customer environments are just so different. You couldn't possibly have one-size-fits-all. It is almost impossible.

We had Dynatrace guardians onsite. 

I would definitely recommend Dynatrace. I would say not to be fearful and embrace it. It is a combination of personal comfort level in your staff, so I would probably recommend you start with a medium to low profile application and just aggressively implement Dynatrace. Once you get accustomed to it, then go with the all-in adoption. 

It is a great product, but your staff and your people, unless you are completely turnkeying it for someone else, they have to understand it. You implement it, and if people don't understand it and use it, then you are really not getting anywhere. That is probably the key part I would make to any recommendation, make sure you train your people or bring in the guardians or use the guardian for six months.

Our technology is constantly evolving. Obviously, the tools like Dynatrace we do hope and expect, frankly, that they will continue to evolve the AI element. I still think there is room in AI technology. Obviously it is getting better all the time. Voice assistant products are obviously the new thing now. So, there are a lot of changes in that technology. My expectation is that we will get way more sophisticated AI alerting and monitoring capability in Dynatrace and we will be happy to embrace it as it becomes available.

If I had just one solution that could provide real answers, not just data, the immediate benefit to my team would be to reduce human interpretation where you have to log on and interpret data. Any automated interpretation on a user's behalf, or operational team, it will be better.

Our primary use case is, we're using AppMon as our main tool for capacity and performance, my team is in charge of all of application performance. 

For us AppMon is unbeatable in the market. We have tried to find other vendor solutions because of the pricing - we're trying to save money - and we couldn't find any other tool that gives us the same amount of information in terms of performance and root cause analysis.

It performs very well if you right-size the infrastructure where you have to deploy it.

I won't say that it improved how our organization functions, but it has improved the time that we need to detect problems; not only before going into production, but problems in production.

Problems in production took us a long time, before, to find the real cause. With this tool, we find them in a very short time. In matter of minutes, we know what the problem is. We are in the banking industry, and in the banking industry you can't allow yourself to be offline.

For us, it improved our SLAs with the business side of our company.

The memory dumps, the tracing, and PurePath. All the tracing that you can do with the tool is, for us, our life. It's our daily job and it saves us a lot of time looking for performance issues.

Something that we have been talking about with the people, here at the Perform 2018 conference, and with the project manager is: On the one hand we have Dynatrace, on the other hand, we have AppMon. We know Dynatrace is more powerful, with a lot of functions, but there are some core functions AppMon has that Dynatrace needs. Our main use is AppMon and we have not gone to Dynatrace because we don't have those specific functions that we need.

If Dynatrace changed it and included all those functions, we would definitely go to Dynatrace, but without them, we stay with AppMon.

At the beginning we used a small infrastructure and we had some problems. With enough capacity it performs very well.

We feel quite comfortable with the scalability, because we have a very huge environment. We have more than 10,000 agents installed, and we have scaled from the beginning. Right now, we have bought a lot more agents because we are deploying microservices and, for us, it works.

They were helpful. They pinpointed exactly what the problem was, because for us it was a strange behavior. It was not downtime, but we lost metrics sometimes, and not always at the same time. We found that it was because the lack of capacity of the servers where we installed the server part of Dynatrace. 

We did not have to wait for answers from them.

We used an in-house developed solution and we had another solution, CA Wily. We decided on Dynatrace because of the features. Dynatrace has a lot more features than what we had and at that time.

We were in CA Wily and we tried, I think, something from IBM at that time. We decided to go with Dynatrace because it was the best for us. In the nine years that we've been with Dynatrace, from time to time we research the market to find out if there's any other solution. In IT, there's always a lack of budget, you should save cost whenever possible, but in those years we haven't find another one.

We discovered the AI capability of Dynatrace previously, and we are willing to go  there, but we haven't gone there yet. We think it's important because right now we have a team of six or seven people working with this, and the AI would allow us to use those people in other tasks, rather than looking for performance issues.

We have used some other monitoring tools in the past and still are right now. We have a lot of them, to give what Dynatrace provides in just one app. That's a challenge because our organization is big. A problem of being big is that deploying a lot of tools is very difficult and it's not the same as deploying only one tool. Deploying only one tool is easier than deploying more than one and keeping up to date with the new versions. With several tools, it's very difficult. For us, that's a key factor of Dynatrace, not only the AppMon but the whole suite gives us a lot of information that, if you want to have it without Dynatrace, you would have to have a lot of tools installed.

The immediate benefit of one solution that would not only give data but real answers, would be time savings.

Our most important criteria for working with a vendor are that they meet our technical requirements and give us support; and support in Spain, and in Spanish, that is very important for us. We like to work with companies that understand us and work with us, who will be partners.

I rate this solution a 10 out of 10 because, as I said, there is no other like this right now. Probably, there are some things that other tools could do, but not everything together.

We have been using Dynatrace for almost two years now. Our primary focus is to understand where the critical bottlenecks are. We have a wide range of applications running on technologies right from mainframe: the client server, cloud, Node.js, etc. 

In order to accommodate all these things, we were looking at one simple product which would help us with all these issues that we were facing. Before choosing Dynatrace, we did a survey of the market to understand what other products there were. 

We ended up choosing Dynatrace because of fantastic capabilities, which it provides. Our business is critical to our customers. With a variety of technologies and different groups, we are experiencing more diverse issues.

The issues are identified well ahead of time because there are a series of operations that form the upstream and downstream applications. The earlier we catch an issue in one of the upstream applications, we can handle it and put a mechanism in place to effectively handle the downstream applications. Without that in place, if something breaks in upstream, then we are definitely sure that some application in downstream will be affected. This is really critical.

PurePath. In addition to routing mechanisms, they have set up the latest profiles and the latest threshold for alerts that go to several teams, including development, support, and infrastructure teams. This helps us be ahead of the game before something happens.

A couple of things that we have actually pointed out in the past:

1. The log analytics, which OneAgent should be carrying forward.
2. Getting the data out of Dynatrace and consuming it in development for other analytical purposes. The analytics feature provides us some information, but is limited for now. We want to see how we can consume the data further down and have analytics guys look at the datacenter information.

We have been running it for more than two years now. We have never had issues with the platform. One hiccup was the front-end server being low in memory because many users logging and running a wide range of reports. So, we limited that to some information by moving some of our users to the platform. In terms of stability, we have never had any issues.

It is scalable. We initially started with fewer agents because we just wanted to have the development team working with this new product. Therefore, we started small and have not had any issues scaling up to what we have. We never had any incidents because of it neither in VM or physical boxes.

The role of AI when it comes to IT's ability to scale in the cloud and manage performance problems is definitely very important. The sheer volume of data we are creating from across all these systems is one of the critical pieces of the enterprise window that happens from 4:00 to 7:00 PM EST, where we send out all the NAV updates to various clients including NASDAQ. There are a variety of products which have their own limitations and quality of information. It is necessary to focus all the important technologies into a single source so we can follow the timelines and know exactly who is going to call us.

With the new managed OneAgent, that is what we're looking at. Currently, we are on AppMon, so we need the AI metrics in place at least until the process of OneAgent to manage the elements that is there. Then, we will see the critical elements and information.

We had to use technical support before, primarily in the areas of adding additional features to the product. For example, we have some applications in Python. We do not have support for Python, which is not really the product, but more adding features on top of the product.

We have used siloed monitoring tools in the past and some of them are already part of the infrastructure vertex system. Then, some are home grown, so we have a good system which is homegrown and looks at various metrics. It is a challenge because we have to write one solution which can handle everything, and our timeframe and resource constraints are a long process in writing. 

I was not involved right at the beginning. It was not complex at all. We had the Dynatrace agent helping us in person with the issues.

Look at Dynatrace. It has helped us by reducing the number of incidents that we have had in the past. It is a robust solution that would help anyone get to the solution and resolution pretty fast.

Most important criteria when selecting a vendor: It came down to a critical component because we have numerous applications with different problems from apps or databases. Before the APM platform for narrowing down the problem became a critical issue, so at this point it was narrowing down and pointing to the exact core component. That was very critical.

Primary use case is for application performance management. So far, we have instrumented 19 of the 72 critical applications, and it is performing well.

We display it on a big dashboard, allowing the teams to look at performance for each app within a group. Thus, it has a little bit of competition, if you will, such as my app is green and yours is not. Not only that, it allows us to see issues sooner rather than later and see the correlated issues. This is very important, because where I work many of the systems are integrated, or using the same underlying infrastructure. The tool allows us to see if it is an infrastructural related issue and see what is affected right away.

• Ease of use
• Ease of integration

There were a number of marketing promises that were made, which we do not see it in the tool yet. 

The integration between the web monitoring of Dynatrace and OneAgent. 

On the technical side, it appears good. It does not always translate on the financial side. 

The technical support has been fair. We have Dynatrace folks still working on the implementation stage so we have not used the full tech support. It is in-house support right now. 

My complaint is the feature sets that they promised slips a lot. However, that is software development. 

We have used siloed monitoring tools in the past. We have had challenges with its integration. 

We did an interview of all the applications and figured out what our gaps are. We identified performance monitoring as a major gap, then we did a number of vendor evaluations and tool evaluations, and our leadership picked Dynatrace. 

The initial setup was straightforward.

Make sure your leadership buy-in is in place. Ensure leadership understands that an APM solution is a fairly expensive, so they know what they are getting into. Tools come and go, but it is the vendor relationship that is important. 

We compared Dynatrace to other vendors. It is cleaner and more compact with good UX/UI.

AI's role is very important when it comes to IT's ability to scale it in the cloud and manage performance problems. AI is the next step in our digital transformation initiative. However, we need to do some simplification of the environment before we can do it.

If I had just one solution that could provide real answers, not just data, the immediate benefit would be people will be much happier. When you have a team that is looking at several hundred applications, if they have to visit eight different tools (or eight different dashboards) to get status, then it is cumbersome. Therefore, you want a centralized solution that allows you to integrate with same products, but not just the same products, any product that whether it is Dynatrace, CA, or BMC. If you are able to grab the data from the siloed solutions into a centralized repository or centralized GUI, it makes it simpler for everybody else.

Most important criteria when selecting a vendor: How the vendor works with us, and whether or not they are a partner or just a customer. Just trying to get more dollars out of the customer instead of working to be a partner, and both in helping to implement the tool and supporting it after the implementation.

The primary reason for choosing any APM solution, it comes through the interface, is to find out the gaps between the application life cycle when someone makes a transaction. Then, we will not know what is causing it to come back so late, delayed, or with latency. We just want to know the pain points of it. That is why we have chosen this APM solution. So far, it is doing a good job, except for some flaws, but that is fine. 

When Dynatrace shows us an entire lifecycle. I can go back to my document and see A points to B, then B points to C, and so on. I can then back and see that I plugged it in every box to see how it is behaving and how the product is dynamically showing the AI behaving in a single place, like on a single webpage. This helps us to see the troubleshooting points or what is hiccuping. This is where we go. We reboot, fix it, or do whatever it takes for it to be taken care of.

The PurePath is one feature, which I actually like. When I have a problem that is being detected by the alerting profiles, I just go in and see what the part is talking to, then what its dependencies are. For example, if a middleware application is behaving weird, then has to be sampled by different databases back-ends, or mainframes, we just keep looking at those PurePath to see what it is talking to rather than going back to my library or my documents to see what exactly the architecture design was. The PurePath helps me a lot.

1. To improve in Dynatrace the log analytics, this is the first thing that has to be enabled. 
2. We are using Splunk or Sumo Logic as an enterprise logging tool. We have been there for a long time, since even before the Dynatrace was. There were Splunk APIs that have been exposed, and we can grab the data from there. Dynatrace also has APIs, but they are unfriendly APIs. If they were friendly like Splunk or Sumo Logic had, we might integrate that same data on a single webpage, then start showing these internally. That would be a great help of a feature; friendly APIs.

Artificial intelligence depends upon business to business. If you take a travel industry, like airlines, not every month will remain the same as in the next 12 months. Our busy seasons would be around summer, Thanksgiving, Christmas, and New Year (two bottleneck seasons). If you come back and are replicating that scenario of traffic of those issues, or those latency of responses being triggered, it will not be the same as in the rest of the months. When we are plugging in the AI, we need it to have in mind this for each and every business, that the AI implementation should be different.

What happened was when there was an AI sneak peek to our portfolios for our company took an average of the last three months, which would not work for us. If it is taking an average of the first three months, say Jan, Feb and March. Our systems would be quiet because we are not handling our bottleneck capacity of traffic. Then, when it comes to April or May, that is where our busy business season starts. The AI takes the alerting profiles of the first three months, then tries to implement on those next three months, or the next coming 24 hours, and then it just screams a lot.

The AI should be tweaked for the last full year, like smart scheduling. That would help us.

Dynatrace solution is pretty much stable. 

Last time, when there were upgrades being made, the alerting profiles had been wiped off, then we had a gap. When Dynatrace made the latest upgrades, newest patch upgrade, or firmwares, the existing alerting profile, which says, "Call me when you see this," or "Call me when you see 10% of these," had been wiped off. Someone has to redo it again. Except that, it has been fixed in the next release. 

The scalability of the solution is good. We initially started with the first three major critical applications, which is where I was introduced to this tool. Right now, they are moving on to the top 21 applications, which is going to be good scalability. They did well.

I have not contacted any customer solution or support.

Since we are still on the warranty period, we have still Dynatrace guardians on-site. I can go in and say, "Hey, this is what is happening," and he will get me a solution, or he will say, "Hey, you are doing this wrong. You have to do this." If not, he would say this feature is not yet released, and we are going to have it in next Q release, or whatever. Dynatrace guardian is the first point of contact if I have to ask any questions, he would be the guy.

We never had a centralized application for performance monitoring tool before Dynatrace. 

Everyone has Sumo Logic. Someone has Splunk. Someone has Tealeaf. Someone has Riverbed. No one had a consistent idea of what another team was doing for monitoring solutions. When enterprise monitoring took place, that was where a centralized solution needed to come in. 

For example, if I was sending a transaction to a different team, and I called it as a transaction, but someone else named it with a Tealeaf ID. There was a disconnect in naming conventions. 

When the APM solution came into place, I now know what to call it and they know what to expect from me, so we are on the same page. This helps us in shortening down the time for triaging an issue.

The capacity planning was complex. Everything else was easy.

Our infrastructure setup has been there for quite a long time, then we already had JVMs who monitor our process. We needed to evaluate what options and what benefits were coming down on our plate, then what was a repetitive task which was already being done by other JVMs. We had to evaluate those on different boxes, different portfolios, etc. Then evaluating options were a little tough because we were already using some things and we had to do something new basically from scratch again. This took some time. After we had experience with the first three major applications, we knew what to do with the next 21. 

If I had a colleague interested in purchasing Dynatrace, I would ask these questions:

• What are you using these days?
• What are you missing? 
• If you have that missing point as well as what you already have, why not go for Dynatrace?

If I had just one solution that could provide real answers, not just data, the immediate benefit would be fixing the issues first. It takes a lot of time for us to dig back where the actual issues on the code base are, especially if it is a network or infrastructure-related. To get answers for most of it, we can fix our issues faster on a priority basis.

Most important criteria for selecting a vendor: Show me what I am not seeing. If you ask me, I am an engineer. I do not want to see the eyes on glass all the time. I want a solution which does it for me. I know how to set my thresholds and throttles. For example, if there is an issue, an exception, or a false exception which is coming in, I know my application:

• If it comes 100 times a day, don't worry about it.
• If it comes five times a minute, don't worry about it. That is the business clients calling improperly.
• If it happens 500 times in a five minute timeframe, then send me an alert.

That is the something which I like a lot regarding the synthetics of application performance monitoring. When I am not seeing and I am being called when there is an issue, which I set my own rules, that is a good idea. That is the great thing and a driving factor for having an APM solution. 

The primary use case for the solution is our application performance and the stability of our application. It really helps provide stable customer-facing applications and we use it continuously monitor our performance.

It is really working well for us and we are negotiating an extended contract right now for the next three years.

Once we started adopting this tool, it become an integral part of our business goals. As an industrial manufacturing company, the big investment and the interest area for us is to have our presence in the e-commerce platform, with stable and performing applications. This is a very critical business goal. 

A monitoring solution like Dynatrace is becoming a very integral part of that particular solution chain. Be it the CDN platform, or commerce platform, application performance monitoring is becoming a very critical piece.

The most valuable feature of the solution is the visibility. It creates visibility - from when the user starts interacting with our application - all the way back to our database calls, our network path, everything. 

The triaging is amazing. And at the same time, it provides depth, all the way to what kind of a method, what variables are inside those methods. Without getting too into the technical, the depth it gets to, pinpointing the problematic area - where exactly the problem is happening - is amazing. That's the best you can get from this tool.

From the Dynatrace SaaS platform, they talk about the APIs. The approach they take is, "We create the APIs, you use them however you want." I like it, that gives us flexibility. But at the same time, if your company does not have a huge number of APM specialists, or it does not have the time and resources available to spend on these kind of technology developments, it would be helpful if there were out-of-the-box solutions available from the platform. I would certainly consider that, because that would make us go to market much faster, rather than redeveloping our own solutions based on those APIs. 

So I would like to see more out-of-the-box solutions developed on those APIs.

And then, we would still have the flexibility to use the APIs if we needed to extend.

What we have right now, is fairly stable because it's not like we're getting an update every year, or every two weeks. When we evaluated the SaaS/Managed services, that's a big question we asked, because if your run-data is going to update you every two weeks, it means worrying about my performance monitoring solution now, rather than worrying about my application. That was a real concern we had. 

The first question we asked is, "Is there an option for us to turn it off? Can decide when we want to update our solutions?" That's an insurance policy for me. If it does not work out for us, we would always have an option. That's a real concern for us, even now. But since we have that insurance, we have an option to turn it off, if we don't want to have it updated every two weeks, I think we are ready to take that risk now.

It does scale really well. We started with monitoring a very limited number of applications, and then we started expanding our scope, and we have kept on adding more and more applications under this portfolio.

We actively use the Expert Services from the vendor. They are certainly very knowledgeable on the solution. The challenge is how do we map our business requirements and business challenges with the solution. Obviously, they do not understand our business challenges, so if we are able to provide the proper feedback to them about our business challenges, they can really map the solution to our problems.

They have solved our problems most of the time, as quickly as possible. Some of the time they solved the problem, but it took some time to solve it. That's the reason I give the solution an eight out of 10. The Expert Services is really helpful for us.

We were referred by one of our vendors. It was more like an architectural review service that we had engaged. When they came out and reviewed our architecture, they made a lot of recommendations on the architectural changes, and the way we need to adapt our commerce platform. 

One of the major recommendations we got from them is, "You really need to start investing in your APM strategy, because that's going to benefit you in the long run." And then we started investing in a very limited amount, to see the return on investment. We saw the value, and then we started increasing every investment on this area.

I was involved in the initial proof of concept, and setting up of the solution. The solution is very straightforward. Setting it up, and then getting it implemented, and then adoption are really complex.

We had our own shortcomings on the technology side. At the same time, I also felt like even Dynatrace has to mature in its offering. They are in the industry as an APM leader, so they should be able to come and say, "Hey, if you are in this vertical, these are the industry best practices. If you follow this, this would be the right path." 

I think that's something Dynatrace has to evolve. Rather than just concentrating on the solution side, they should focus more on the business side. For example, they should say, "For your retail, this is how your application performance monitoring happens. If you're in the manufacturing industrial segment, this is how the application performance monitoring happens, these are the key metrics you should look for."

We went automatically with the referral to Dynatrace. We already had enterprise APM solutions available, so they started competing with the Dynatrace. From time to time, we still evaluate other vendors, but we are still sticking with Dynatrace for two reasons. 

First, they have always been ahead of the market. When we started thinking, "Okay, we want to do a DevOps strategy, and continuous deployment, continuous integration. Dynatrace has an offering which will fit into those particular requirements." 

And the second one is, they have already spent three years with us, so they know our business, they know our business strategies, and our business goals. I've not really had appetite to go back and start investing my time and energy with a new vendor to bring them on board and then teach then everything that I have already taught to the Dynatrace guys.

Regarding the role of AI when it comes to IT's ability to scale into the cloud, and monitor performance management issues, the way I look at AI is this. When we started this journey three years back, it was more like problem-solving. We have a problem, and we need to identify the root causes and how do we solve it? That's what it was three years back. 

In three years, a lot of things have changed. Now it's all about, how do you proactively monitor it, and how do you solve it, and then the self-healing techniques and the like. So even without a developer looking into it, how do you solve the problem? That's the big thing I'm seeing from our organization's point of view on AI. The second point is, we are also starting our DevOps initiatives, and then the continuous integration platforms, and continuous delivery platforms. The AI platform, and the new Dynatrace, is becoming a critical value in that as well.

In terms of siloed monitoring tools, our team has not used them, but our enterprise had other application monitoring tools. The challenge with those are that some of them are really concentrating on your networking site, some of them are concentrating on your specific application-oriented issues. You are not able to get one big picture, or a single pane of visibility into every application or every service that's involved in that application. That's where I think this particular solution helped us a lot.

If there is one solution, it reduces the complexity. If you bring one solution, there would be some learning curve to adopting the solution, but in the long run it's going to really help to reduce the complexity. From my team's point of view, they would be able to go much deeper, picture a "T" shape, rather than a horizontal. Otherwise, you would need to learn one tool for this particular technology, or for this application, and another tool to support another application. So if there is one tool, they could go all the way, and there would be a lot of productivity improvement because of that.

As far as selecting a vendor goes, what's important to us are two things. First, are they stable enough. Is the company stable enough to do business with them, because we are a 100-year-old company, so we value the continuity of the business. Second, how visionary are they in their market, in that industry? We don't take too much risk on any evolving technology. We wait until the technology evolves and matures. That's a very critical thing. 

We always look for how strong they are in that industry, how long they are in this industry, what their track record is, and what their future looks like.

My advice is, involve all the stakeholders from day one. Bringing everyone on board from day one, and get everybody onto the same page, what they want from the solution. That is very critical. It takes some time to get it to a maturity level, and then adoption. That means you start adopting it, and then six months down the line, if your business or a different team comes back and says, "This is good, but it's not really making any sense to me," then the whole six months, whatever you invested, has really gone to waste. Or you need to redo things one more time for them.

So I would say, identify all the stakeholders who will be consuming this solution, and then start engaging with them on day one. Even if they are not going to be part of the solution, or consuming these services, from day one, identify all of them and keep them engaged from day one. That will be very critical. We made that mistake and we learned from that.